View source for Ubuntu To Ubuntu Connection Test

== Mikrotik Ubuntu L2TPv3 — Testing Hub and Remote Ubuntu ==



این صفحه راهنمای کامل تست و عیب‌یابی تونل L2TPv3 بین '''Hub Ubuntu''' و '''Remote Ubuntu''' است. هر روش تست با دستور، جدول تفسیر نتیجه و توضیح مفصل ارائه شده است. IPهای واقعی با placeholder جایگزین شده‌اند تا در wiki عمومی قابل انتشار باشد. ترتیب اجرا از ساده (لایه تونل) به پیشرفته (throughput و capture) پیشنهاد می‌شود.



'''مرتبط:''' [[Mikrotik_Ubuntu_L2TPv3]]



----



=== Topology (این سناریو) ===



{| class="wikitable"

|-

! نقش !! Public IP (placeholder) !! Tunnel IP (placeholder) !! Interface

|-

| Hub || <code>HUB_PUBLIC_IP</code> || <code>HUB_TUNNEL_IP</code>/30 || l2tpeth1

|-

| Remote || <code>REMOTE_PUBLIC_IP</code> || <code>REMOTE_TUNNEL_IP</code>/30 || l2tpeth0

|}



'''مثال subnet تونل (قابل تغییر در طرح IP شما):'''



* <code>HUB_TUNNEL_IP</code> = 10.0.1.1

* <code>REMOTE_TUNNEL_IP</code> = 10.0.1.2

* Subnet NAT روی Hub: <code>10.0.1.0/30</code>



----



=== Prerequisites (پیش‌نیاز قبل از تست) ===



قبل از اجرای تست‌ها موارد زیر باید برقرار باشند:



* سرویس <code>ql2tpd</code> روی هر دو سرور در وضعیت <code>active (running)</code> باشد

* اینترفیس تونل IP داشته باشد: Hub روی <code>l2tpeth1</code>، Remote روی <code>l2tpeth0</code>

* روی Hub قوانین NAT و FORWARD برای subnet تونل Remote اعمال شده باشد

* روی Remote policy routing با <code>from REMOTE_TUNNEL_IP lookup 100</code> فعال باشد

* ابزارهای تست: <code>curl</code>، <code>iperf3</code>، <code>tcpdump</code> (در صورت نبود: <code>apt install -y iperf3 tcpdump</code>)

* برای تست IP عمومی از سرویس قابل دسترس در شبکه خودتان استفاده کنید (مثال: <code>https://api.ipnote.ir/myip</code>) — در ایران از سرویس‌های فیلترنشده استفاده کنید



'''توضیح:'''



تست‌های این صفحه فرض می‌کنند تونل L2TPv3 با encapsulation IP (پروتکل ۱۱۵) یا UDP (پورت ۱۷۰۱) بین Hub و Remote برقرار شده است. اگر هنوز اینترفیس <code>l2tpeth*</code> ساخته نشده یا در حالت DOWN است، ابتدا بخش عیب‌یابی پروتکل ۱۱۵ (Step 6) را اجرا کنید. selective routing روی Remote به این معناست که فقط ترافیک با source برابر <code>REMOTE_TUNNEL_IP</code> از تونل خارج می‌شود و بقیه ترافیک سرور (از جمله SSH و پنل مدیریت) از IP عمومی <code>REMOTE_PUBLIC_IP</code> می‌رود. بنابراین تست «اینترنت عادی» و «از تونل» را همیشه جدا انجام دهید. Hub باید <code>ip_forward</code> فعال و MASQUERADE برای subnet تونل Remote داشته باشد؛ بدون آن ping به <code>HUB_TUNNEL_IP</code> ممکن است OK باشد ولی خروج به اینترنت از تونل fail شود.



----



=== Step 1 — Ping tunnel endpoints (تست لایه تونل) ===



این ساده‌ترین تست است و فقط ارتباط IP بین دو انتهای pseudowire را می‌سنجد، بدون دخالت NAT یا اینترنت.



==== From Remote to Hub ====



 ping -c 4 HUB_TUNNEL_IP



==== From Hub to Remote ====



 ping -c 4 REMOTE_TUNNEL_IP



{| class="wikitable"

|-

! نتیجه !! تفسیر

|-

| 0% packet loss || تونل برقرار است — به مرحله بعد بروید

|-

| 100% packet loss || ql2tpd، فایروال proto 115، IP اینترفیس یا peer down را بررسی کنید

|}



'''توضیح:'''



دستور ping بین <code>HUB_TUNNEL_IP</code> و <code>REMOTE_TUNNEL_IP</code> مستقیماً روی subnet تونل اجرا می‌شود و نیازی به NAT روی Hub ندارد. اگر این تست موفق باشد یعنی session L2TPv3 برقرار شده، اینترفیس‌های <code>l2tpeth0</code> و <code>l2tpeth1</code> آدرس گرفته‌اند و بسته ICMP از یک طرف به طرف دیگر از داخل تونل رد می‌شود. تأخیر (RTT) معمولاً برابر فاصله جغرافیایی بین دو سرور عمومی است؛ مثلاً اگر Hub در اروپا و Remote در ایران باشد، RTT حدود ۶۰ تا ۹۰ میلی‌ثانیه طبیعی است. اگر ping صفر درصد loss دارد ولی تست‌های بعدی (خروج به اینترنت) fail می‌شوند، مشکل در لایه تونل نیست بلکه در NAT، forward یا policy routing است. همیشه ping را از هر دو جهت بزنید تا مطمئن شوید مسیر برگشت هم باز است.



----



=== Step 2 — IP egress test (تمایز اینترنت عادی و تونل) ===



==== Normal internet (بدون تونل) — run on Remote ====



 curl -4 -s "https://api.ipnote.ir/myip"



==== Forced via tunnel — run on Remote ====



 curl -4 --interface l2tpeth0 -s "https://api.ipnote.ir/myip"



{| class="wikitable"

|-

! خروجی curl !! معنی

|-

| REMOTE_PUBLIC_IP || ترافیک از WAN مستقیم خارج شده

|-

| HUB_PUBLIC_IP || ترافیک از تونل و NAT Hub خارج شده

|-

| timeout / خطا || policy routing Remote یا NAT Hub ناقص است

|}



'''توضیح:'''



این تست مهم‌ترین معیار selective routing روی سرور Remote است. دستور اول بدون bind به اینترفیس تونل اجرا می‌شود و باید IP عمومی خود Remote را نشان دهد؛ این تأیید می‌کند سرور به‌طور عادی به اینترنت دسترسی دارد. دستور دوم با <code>--interface l2tpeth0</code> اجبار می‌کند اتصال HTTPS از اینترفیس تونل برود؛ در این حالت kernel باید source address برابر <code>REMOTE_TUNNEL_IP</code> انتخاب کند و با rule <code>from REMOTE_TUNNEL_IP lookup 100</code> بسته از Hub NAT شده و با IP <code>HUB_PUBLIC_IP</code> به اینترنت برود. اگر خروجی دوم <code>HUB_PUBLIC_IP</code> نیست، یا policy routing روی Remote ناقص است یا NAT/forward روی Hub. این تست را قبل از هر تنظیم x-ui انجام دهید؛ اگر در OS درست کار کند ولی کلاینت VPN اشتباه است، مشکل در routing ruleهای پنل 3x-ui است نه L2TP.



----



=== Step 2b — Latency breakdown with curl (تفکیک DNS، TCP، TLS) ===



==== Via tunnel ====



 curl -4 --interface l2tpeth0 -s -o /dev/null -w "DNS:%{time_namelookup}s  TCP:%{time_connect}s  TLS:%{time_appconnect}s  Total:%{time_total}s\n" "https://api.ipnote.ir/myip"



==== Direct (بدون تونل) — مقایسه ====



 curl -4 -s -o /dev/null -w "DNS:%{time_namelookup}s  TCP:%{time_connect}s  TLS:%{time_appconnect}s  Total:%{time_total}s\n" "https://api.ipnote.ir/myip"



==== Quick total via tunnel ====



 curl -4 --interface l2tpeth0 -s -o /dev/null -w "Total:%{time_total}s\n" "https://api.ipnote.ir/myip"



{| class="wikitable"

|-

! فیلد !! معنی !! اگر زیاد باشد

|-

| time_namelookup || زمان DNS resolve || DNS کند یا فیلتر — rule DNS در x-ui را چک کنید

|-

| time_connect || زمان TCP connect || مسیر تونل یا RTT بالا

|-

| time_appconnect || پایان TLS handshake || latency مسیر Hub

|-

| time_total || کل درخواست || معمولاً ۰.۴ تا ۱ ثانیه از تونل طبیعی است

|}



'''توضیح:'''



این تست به شما کمک می‌کند «کندی» را از «خرابی» جدا کنید. وقتی <code>time_namelookup</code> زیر چند میلی‌ثانیه است، DNS مقصر کندی نیست. تفاوت <code>time_total</code> بین مسیر مستقیم (مثلاً ۰.۰۶ ثانیه) و مسیر تونل (مثلاً ۰.۴۷ ثانیه) به‌خاطر bug نیست؛ ترافیک از Hub در کشور دیگر خارج می‌شود و یک hop و RTT اضافه دارد. این trade-off عمدی selective routing است: IP خروجی <code>HUB_PUBLIC_IP</code> با هزینه latency بیشتر. توجه کنید <code>curl --interface</code> فقط اتصال TCP را bind می‌کند و resolve ممکن است هنوز از resolver سیستم برود؛ برای تست DNS واقعی کلاینت x-ui به rule پورت ۵۳ → outbound تونل نیاز دارید. اگر Total چند ثانیه یا بیشتر است در حالی که iperf خوب است، سراغ DNS و routing پنل بروید نه MTU تونل.



----



=== Step 3 — Ping internet via tunnel (ICMP به اینترنت از source تونل) ===



 ping -4 -I l2tpeth0 -c 4 8.8.8.8



'''اجرا روی:''' Remote



{| class="wikitable"

|-

! نتیجه !! تفسیر

|-

| پاسخ از 8.8.8.8 || forward و NAT روی Hub فعال است

|-

| 100% loss ولی ping HUB_TUNNEL_IP OK || تقریباً قطعی مشکل NAT یا FORWARD روی Hub

|-

| Network unreachable || policy routing یا route در table 100 ناقص است

|}



'''توضیح:'''



برخلاف ping به <code>HUB_TUNNEL_IP</code> که فقط داخل subnet تونل است، این تست بسته ICMP را با source <code>REMOTE_TUNNEL_IP</code> به آدرس اینترنتی (مثلاً 8.8.8.8) می‌فرستد. بسته از تونل به Hub می‌رسد، Hub باید آن را forward کند، NAT (MASQUERADE) بزند و از WAN خارج کند؛ پاسخ ICMP باید برگردد و دوباره از تونل به Remote برسد. اگر Step 1 موفق و این تست ۱۰۰٪ loss است، تقریباً همیشه مشکل روی Hub است: <code>net.ipv4.ip_forward=0</code>، نبود rule MASQUERADE برای subnet تونل، یا FORWARD بین <code>l2tpeth1</code> و <code>WAN_INTERFACE_HUB</code> بسته است. گاهی <code>rp_filter</code> strict روی Hub یا اینترفیس تونل باعث drop نامتقارن می‌شود؛ مقدار ۰ برای تونل و WAN توصیه می‌شود. برخی شبکه‌ها ICMP را محدود می‌کنند؛ در آن صورت به Step 2 (curl) تکیه کنید.



----



=== Step 4 — Throughput test with iperf3 (تست سرعت بین دو سرور) ===



==== Install (یک‌بار روی هر دو سرور) ====



 apt install -y iperf3



==== Server on Hub ====



 iperf3 -s -B HUB_TUNNEL_IP



==== Upload Remote → Hub ====



 iperf3 -c HUB_TUNNEL_IP -B REMOTE_TUNNEL_IP -t 10



==== Download Hub → Remote (reverse) ====



 iperf3 -c HUB_TUNNEL_IP -B REMOTE_TUNNEL_IP -t 10 -R



==== Parallel streams ====



 iperf3 -c HUB_TUNNEL_IP -B REMOTE_TUNNEL_IP -t 10 -P 4



{| class="wikitable"

|-

! شاخص !! مقدار قابل قبول (تقریبی) !! تفسیر

|-

| Throughput || صدها Mbps تا نزدیک 1 Gbps || بسته به لینک فیزیکی دو سرور

|-

| Retr (retransmits) || نزدیک 0 || بالا = MTU، congestion، یا نیاز به BBR

|-

| -R vs بدون -R || هر دو بالا || اگر فقط -R کند است، TCP tuning (BBR) روی Hub و Remote

|}



'''توضیح:'''



iperf3 تنها تستی است که throughput واقعی TCP روی تونل را اندازه می‌گیرد، نه فقط latency اولین اتصال. سرور iperf باید روی Hub و فقط روی <code>HUB_TUNNEL_IP</code> bind شود تا ترافیک تست از WAN عبور نکند. کلاینت روی Remote با <code>-B REMOTE_TUNNEL_IP</code> اطمینان می‌دهد تمام جریان از policy table 100 و تونل می‌رود. تست بدون <code>-R</code> جهت Upload (Remote به Hub) را می‌سنجد؛ با <code>-R</code> Hub ارسال می‌کند و جهت Download را می‌سنجد — در تونل‌های با RTT بالا بدون BBR ممکن است Download کندتر باشد. <code>-P 4</code> چهار TCP موازی باز می‌کند و سقف واقعی لینک را بهتر نشان می‌دهد. Retr بالای چند صد در ۱۰ ثانیه با throughput خوب معمولاً قابل چشم‌پوشی است؛ Retr زیاد با throughput پایین یعنی MTU 1400، MSS clamp، یا congestion control را بررسی کنید. اگر iperf نزدیک ۱ Gbps است ولی کاربر x-ui کند است، مشکل throughput تونل نیست.



----



=== Step 5 — tcpdump on tunnel interface (مشاهده ترافیک زنده) ===



==== Install ====



 apt install -y tcpdump



==== Capture ====



 tcpdump -ni l2tpeth0 host REMOTE_TUNNEL_IP



'''اجرا روی:''' Remote — هنگام اتصال کلاینت 3x-ui یا اجرای <code>curl --interface l2tpeth0</code>



{| class="wikitable"

|-

! مشاهده !! معنی

|-

| پکت‌های <code>REMOTE_TUNNEL_IP →</code> IP خارجی || outbound از تونل فعال است (x-ui یا curl)

|-

| پکت‌های <code>→ REMOTE_TUNNEL_IP</code> || مسیر برگشت و NAT Hub سالم است

|-

| TCP 443 با تبادل داده || اتصال واقعی برقرار — Telegram، Google، Microsoft و غیره

|-

| UDP پورت 3478 || STUN/WebRTC (تماس ویدیو) از تونل — طبیعی

|-

| هیچ پکتی هنگام استفاده کلاینت || inboundTag یا routing rule در 3x-ui اشتباه است

|-

| ARP از HUB_TUNNEL_IP || همسایگی لایه ۲ روی pseudowire — طبیعی

|}



'''توضیح:'''



tcpdump روی <code>l2tpeth0</code> با فیلتر <code>host REMOTE_TUNNEL_IP</code> دقیقاً نشان می‌دهد آیا ترافیک با source تونل از پنل 3x-ui (outbound <code>l2tp-out</code> با <code>sendThrough</code>) عبور می‌کند یا نه. اگر هنگام باز کردن سایت در کلاینت VPN پکت‌های TCP یا UDP با source <code>REMOTE_TUNNEL_IP</code> می‌بینید، outbound کار می‌کند حتی اگر پنل آمار ۰ بایت نشان دهد — برخی نسخه‌های پنل برای outbound نوع freedom آمار را درست به‌روز نمی‌کنند. دیدن پکت برگشتی از مقصد (مثلاً :443) یعنی Hub NAT و forward درست است. UDP به پورت 3478 معمولاً مربوط به STUN برای تماس صوتی/تصویری است و از تونل رد شدن آن طبیعی است. اگر هیچ پکتی نیست ولی curl با <code>--interface l2tpeth0</code> کار می‌کند، کلاینت به inbound اشتباه وصل شده یا rule به outbound دیگری می‌رود. برای خروج از capture: Ctrl+C.



----



=== Step 6 — L2TP protocol 115 capture (عیب‌یابی برقراری تونل) ===



ابتدا نام اینترفیس WAN را پیدا کنید:



 ip route get 1.1.1.1



==== On Hub ====



 tcpdump -ni WAN_INTERFACE_HUB host REMOTE_PUBLIC_IP and proto 115



==== On Remote ====



 tcpdump -ni WAN_INTERFACE_REMOTE host HUB_PUBLIC_IP and proto 115



سپس روی هر دو سرور (در ترمینال جدا):



 systemctl restart ql2tpd



{| class="wikitable"

|-

! مشاهده !! تفسیر

|-

| پکت proto 115 دوطرفه || L2TP در حال مذاکره — اگر l2tpeth DOWN است config ID را چک کنید

|-

| هیچ پکت 115 || فایروال ufw، iptables، یا cloud firewall پروتکل 115 را بلاک می‌کند

|-

| فقط یک طرف || فایروال یک‌طرفه یا asymmetric routing

|}



'''توضیح:'''



وقتی <code>ql2tpd</code> در لاگ می‌نویسد <code>quiescent tunnel</code> ولی <code>l2tpeth*</code> در حالت DOWN است یا ping تونل ۱۰۰٪ loss دارد، باید ببینید آیا اصلاً پکت L2TPv3 با encapsulation IP (پروتکل ۱۱۵) بین دو سرور رد و بدل می‌شود. این تست روی اینترفیس WAN واقعی است نه l2tpeth — نام اینترفیس روی هر سرور متفاوت است (مثلاً eth0 روی Hub و ens160 روی VMware). tcpdump را روی هر دو سرور همزمان اجرا کنید و ql2tpd را restart کنید. اگر هیچ پکتی نیست، در ufw دستور <code>ufw allow proto 115</code> و در پنل cloud firewall اجازه protocol 115 بین IPهای عمومی را بدهید. در برخی دیتاسنترها فقط TCP/UDP مجاز است؛ در آن صورت encap را به UDP پورت ۱۷۰۱ روی هر دو طرف تغییر دهید (فقط تونل Hub–Remote، نه لزوماً MikroTik). خطای <code>dataplane down: no such device</code> هنگام restart معمولاً بی‌ضرر است.



----



=== Step 7 — Policy routing checklist (Remote) ===



 ip rule show | grep REMOTE_TUNNEL_IP

 ip route show table 100

 ip -br addr show l2tpeth0



{| class="wikitable"

|-

! خروجی مورد انتظار !! اگر نیست

|-

| <code>from REMOTE_TUNNEL_IP lookup 100</code> || <code>ip rule add from REMOTE_TUNNEL_IP lookup 100 priority 100</code>

|-

| <code>default via HUB_TUNNEL_IP dev l2tpeth0</code> در table 100 || route default را در table 100 اضافه کنید

|-

| REMOTE_TUNNEL_IP/30 روی l2tpeth0 || IP و <code>ip link set l2tpeth0 up</code>

|}



'''توضیح:'''



selective routing روی Remote بدون تغییر default route اصلی (که از <code>REMOTE_PUBLIC_IP</code> خارج می‌شود) با policy routing انجام می‌شود. table 100 یک routing table جداگانه است که فقط وقتی source بسته برابر <code>REMOTE_TUNNEL_IP</code> باشد استفاده می‌شود — دقیقاً همان کاری که Xray با <code>sendThrough: "REMOTE_TUNNEL_IP"</code> انجام می‌دهد. نباید default route اصلی را به تونل هدایت کنید چون تمام ترافیک سرور شامل SSH و پنل از تونل می‌رود. rule باید با priority مناسب (مثلاً ۱۰۰) قبل از main table اعمال شود. پس از reboot اسکریپت <code>/etc/networkd-dispatcher/routable.d/l2tp-remote-policy.sh</code> باید همین ruleها را دوباره اعمال کند. اگر <code>ip rule</code> درست است ولی curl از تونل fail می‌شود، مشکل در Hub NAT است نه Remote routing.



----



=== Step 8 — NAT and forward checklist (Hub) ===



 sysctl net.ipv4.ip_forward

 iptables -t nat -L POSTROUTING -n -v | grep 10.0.1

 iptables -L FORWARD -n -v | grep l2tpeth1



 WAN detection:



 ip route get 1.1.1.1



{| class="wikitable"

|-

! خروجی مورد انتظار !! اگر نیست

|-

| <code>ip_forward = 1</code> || <code>sysctl -w net.ipv4.ip_forward=1</code> و فایل sysctl.d

|-

| MASQUERADE برای subnet تونل به WAN_INTERFACE_HUB || iptables NAT POSTROUTING

|-

| FORWARD l2tpeth1 ↔ WAN || iptables FORWARD ACCEPT

|}



'''توضیح:'''



Hub نقش gateway برای ترافیک تونل Remote را دارد. وقتی بسته‌ای با source در subnet تونل Remote (مثلاً 10.0.1.0/30) از <code>l2tpeth1</code> وارد Hub می‌شود و مقصدش اینترنت است، kernel باید forwarding فعال داشته باشد و iptables آن را NAT کند تا مقصد پاسخ را به IP عمومی Hub بفرستد و Hub بتواند پاسخ را به تونل برگرداند. فقط NAT برای subnet تونل Remote اعمال کنید — تونل‌های MikroTik ممکن است مسیر خودشان را داشته باشند. <code>IFACE</code> در دستورات iptables باید اینترفیس WAN واقعی Hub باشد (از <code>ip route get 1.1.1.1</code>). پس از تنظیم، <code>netfilter-persistent save</code> بزنید. MSS clamp روی FORWARD TCP توصیه می‌شود تا با MTU 1400 تونل سازگار باشد. بدون این بخش، ping به <code>HUB_TUNNEL_IP</code> OK و ping به 8.8.8.8 از تونل fail می‌ماند.



----



=== Step 9 — 3x-ui / Xray outbound verification (تأیید پنل) ===



پس از تأیید OS با Step 2 و Step 5، پنل 3x-ui را تنظیم کنید.



==== Outbound JSON (مثال) ====



{

  "tag": "l2tp-out",

  "protocol": "freedom",

  "sendThrough": "REMOTE_TUNNEL_IP",

  "settings": { "domainStrategy": "UseIPv4" },

  "mux": { "enabled": false }

}



==== Routing rules (ترتیب مهم) ====



# inbound مشخص → l2tp-out

# port 53 udp,tcp → l2tp-out

# بقیه → direct



'''توضیح:'''



اگر تست‌های OS (curl با interface، iperf، tcpdump) موفق هستند ولی تجربه کاربر نهایی بد است، تمرکز روی 3x-ui است. outbound <code>l2tp-out</code> باید protocol freedom با <code>sendThrough</code> برابر IP تونل Remote باشد؛ mux را false بگذارید. حداقل دو routing rule لازم است: یکی inboundTag دقیق inbound مورد نظر به l2tp-out، و دیگری DNS (پورت ۵۳) به l2tp-out — بدون rule DNS برخی سایت‌ها کند باز می‌شوند یا timeout می‌خورند چون resolve از مسیر مستقیم می‌رود. ruleهای l2tp-out باید بالای direct و geoip باشند. آمار صفر در پنل به‌معنی قطع ترافیک نیست؛ tcpdump (Step 5) معیار قطعی است. IP کلاینت از سرویس myip باید <code>HUB_PUBLIC_IP</code> باشد. latency حدود نیم ثانیه برای اولین HTTPS از تونل طبیعی است و با iperf 900 Mbps تناقض ندارد.



----



=== Step 10 — TCP tuning note (BBR — اختیاری برای کیفیت) ===



فایل <code>/etc/sysctl.d/99-tcp-tune.conf</code> با BBR روی Hub و Remote — پس از تأیید تونل.



'''توضیح:'''



تنظیم BBR و بافرهای TCP روی throughput بعد از برقراری اتصال اثر دارد، نه روی ping یا اولین DNS resolve. اگر iperf در جهت Download (<code>-R</code>) بسیار کندتر از Upload است در حالی که Upload بالاست، فعال‌سازی <code>net.ipv4.tcp_congestion_control=bbr</code> و <code>net.core.default_qdisc=fq</code> روی هر دو سرور توصیه می‌شود. این تنظیمات جایگزین NAT یا policy routing نمی‌شوند. اگر curl از تونل timeout می‌خورد، BBR کمکی نمی‌کند — اول Step 7 و 8 را کامل کنید. پس از اعمال sysctl، یک بار iperf -R را تکرار کنید و Retr و bitrate را مقایسه کنید. BBR برای ترافیک x-ui کلاینت وقتی تونل از نظر OS تأیید شده مفید است.



----



=== Troubleshooting decision tree (درخت تصمیم عیب‌یابی) ===



{| class="wikitable"

|-

! علامت !! احتمال اول !! اقدام

|-

| ping تونل fail || L2TP / proto 115 || Step 1، Step 6

|-

| ping تونل OK، ping 8.8.8.8 از تونل fail || NAT Hub || Step 8

|-

| curl مستقیم OK، curl --interface fail || policy routing || Step 7

|-

| curl --interface → HUB_PUBLIC_IP || OS سالم — x-ui || Step 5، Step 9

|-

| iperf کند فقط -R || TCP tuning || Step 10

|-

| همه OS OK، کلاینت کند || DNS rule / latency مسیر Hub || Step 2b، Step 9

|-

| tcpdump هنگام کلاینت خالی || inboundTag / routing || Step 9

|}



----



=== Expected results summary (جدول خلاصه) ===



{| class="wikitable"

|-

! Test !! Server !! Expected on success

|-

| ping HUB_TUNNEL_IP || Remote || 0% packet loss

|-

| ping REMOTE_TUNNEL_IP || Hub || 0% packet loss

|-

| curl (no interface) || Remote || REMOTE_PUBLIC_IP

|-

| curl --interface l2tpeth0 || Remote || HUB_PUBLIC_IP

|-

| curl timing via tunnel || Remote || Total ~0.4–1s (مسیر Hub)

|-

| curl timing direct || Remote || معمولاً کمتر از tunnel

|-

| ping -I l2tpeth0 8.8.8.8 || Remote || 0% packet loss

|-

| iperf3 upload || Remote || high Mbps, low Retr

|-

| iperf3 -R download || Remote || high Mbps, low Retr (با BBR)

|-

| tcpdump l2tpeth0 || Remote || پکت REMOTE_TUNNEL_IP هنگام کلاینت

|-

| Client IP (x-ui) || Client || HUB_PUBLIC_IP

|}



----



=== Placeholder reference (جدول جایگزین‌ها) ===



{| class="wikitable"

|-

! Placeholder !! توضیح !! مثال subnet (غیر عمومی)

|-

| <code>HUB_PUBLIC_IP</code> || IP عمومی سرور Hub || —

|-

| <code>REMOTE_PUBLIC_IP</code> || IP عمومی سرور Remote || —

|-

| <code>HUB_TUNNEL_IP</code> || IP تونل روی Hub || 10.0.1.1

|-

| <code>REMOTE_TUNNEL_IP</code> || IP تونل روی Remote || 10.0.1.2

|-

| <code>WAN_INTERFACE_HUB</code> || اینترفیس WAN Hub || eth0

|-

| <code>WAN_INTERFACE_REMOTE</code> || اینترفیس WAN Remote || ens160

|}



----



=== Recommended test order (ترتیب پیشنهادی) ===



# Prerequisites و نصب iperf3/tcpdump

# Step 1 — ping تونل دوطرفه

# Step 2 — curl IP مستقیم vs تونل

# Step 2b — curl timing (اختیاری — تفکیک کندی)

# Step 3 — ping 8.8.8.8 از تونل

# Step 8 — اگر Step 3 fail

# Step 7 — اگر Step 2 interface fail

# Step 4 — iperf3 throughput

# Step 10 — BBR اگر -R کند است

# Step 5 — tcpdump هنگام کلاینت 3x-ui

# Step 9 — تنظیم و تأیید پنل

# Step 6 — فقط اگر تونل اصلاً up نمی‌شود



----



[[Category:L2TPv3]]

[[Category:Ubuntu]]

[[Category:Networking]]

[[Category:Testing]]