Ubuntu To Ubuntu Connection Test: Difference between revisions

From wiki karavi
Jump to navigation Jump to search
VisualWikitext
No edit summary
No edit summary
Line 1: Line 1:
== Mikrotik Ubuntu L2TPv3 — Testing Hub and Remote Ubuntu ==
== Mikrotik Ubuntu L2TPv3 — Testing Hub and Remote Ubuntu ==


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


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


----
----


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


{| class="wikitable"
{| class="wikitable"
|-
|-
! نقش !! Public IP (placeholder) !! Tunnel IP (placeholder) !! Interface
! نقش !! Public IP (placeholder) !! Tunnel IP (placeholder) !! Interface
|-
|-
| Hub || <code>HUB_PUBLIC_IP</code> || <code>HUB_TUNNEL_IP</code>/30 || l2tpeth1
| 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
| Remote || <code>REMOTE_PUBLIC_IP</code> || <code>REMOTE_TUNNEL_IP</code>/30 || l2tpeth0
|}
|}


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


* <code>HUB_TUNNEL_IP</code> = 10.0.1.1
* <code>HUB_TUNNEL_IP</code> = 10.0.1.1
* <code>REMOTE_TUNNEL_IP</code> = 10.0.1.2
* <code>REMOTE_TUNNEL_IP</code> = 10.0.1.2
* Subnet NAT روی Hub: <code>10.0.1.0/30</code>
* Subnet NAT روی Hub: <code>10.0.1.0/30</code>


----
----


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


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


* سرویس <code>ql2tpd</code> روی هر دو سرور در وضعیت <code>active (running)</code> باشد
* سرویس <code>ql2tpd</code> روی هر دو سرور در وضعیت <code>active (running)</code> باشد
* اینترفیس تونل IP داشته باشد: Hub روی <code>l2tpeth1</code>، Remote روی <code>l2tpeth0</code>
* اینترفیس تونل IP داشته باشد: Hub روی <code>l2tpeth1</code>، Remote روی <code>l2tpeth0</code>
* روی Hub قوانین NAT و FORWARD برای subnet تونل Remote اعمال شده باشد
* روی Hub قوانین NAT و FORWARD برای subnet تونل Remote اعمال شده باشد
* روی Remote policy routing با <code>from REMOTE_TUNNEL_IP lookup 100</code> فعال باشد
* روی Remote policy routing با <code>from REMOTE_TUNNEL_IP lookup 100</code> فعال باشد
* برای تست IP عمومی از سرویس قابل دسترس در شبکه خودتان استفاده کنید (مثال: <code>https://api.ipnote.ir/myip</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 (تست لایه تونل) ===
=== Step 1 — Ping tunnel endpoints (تست لایه تونل) ===


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


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


  ping -c 4 HUB_TUNNEL_IP
  ping -c 4 HUB_TUNNEL_IP


'''توضیح:''' اگر پاسخ با تأخیر پایدار و بدون packet loss دریافت شد، تونل L2TPv3 سالم است.
 


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


  ping -c 4 REMOTE_TUNNEL_IP
  ping -c 4 REMOTE_TUNNEL_IP


'''توضیح:''' پینگ دوطرفه تأیید می‌کند هر دو سرور اینترفیس تونل را بالا نگه داشته‌اند.
 


{| class="wikitable"
{| class="wikitable"
|-
|-
! نتیجه !! تفسیر
! نتیجه !! تفسیر
|-
|-
| 0% packet loss || تونل برقرار است — به مرحله بعد بروید
| 0% packet loss || تونل برقرار است — به مرحله بعد بروید
|-
|-
| 100% packet loss || ql2tpd، فایروال proto 115 یا IP اینترفیس را بررسی کنید
 
| 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 (تمایز اینترنت عادی و تونل) ===
=== Step 2 — IP egress test (تمایز اینترنت عادی و تونل) ===


مهم‌ترین تست روزمره برای selective routing روی سرور Remote.
 


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


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


'''توضیح:''' باید IP عمومی خود سرور Remote یعنی <code>REMOTE_PUBLIC_IP</code> نمایش داده شود.
 


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


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


'''توضیح:''' باید IP عمومی Hub یعنی <code>HUB_PUBLIC_IP</code> برگردد؛ یعنی NAT روی Hub درست است.
 


{| class="wikitable"
{| class="wikitable"
|-
|-
! خروجی curl !! معنی
! خروجی curl !! معنی
|-
|-
| REMOTE_PUBLIC_IP || ترافیک از WAN مستقیم خارج شده
| REMOTE_PUBLIC_IP || ترافیک از WAN مستقیم خارج شده
|-
|-
| HUB_PUBLIC_IP || ترافیک از تونل و NAT Hub خارج شده
| HUB_PUBLIC_IP || ترافیک از تونل و NAT Hub خارج شده
|-
|-
| timeout / خطا || policy routing Remote یا 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 3 — Ping internet via tunnel (ICMP از source تونل) ===
 
 
=== 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
  ping -4 -I l2tpeth0 -c 4 8.8.8.8


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


'''توضیح:''' بسته با source <code>REMOTE_TUNNEL_IP</code> ارسال می‌شود و مسیر forward و NAT روی Hub را تأیید می‌کند.
 


{| class="wikitable"
{| class="wikitable"
|-
|-
! نتیجه !! تفسیر
! نتیجه !! تفسیر
|-
|-
| پاسخ از 8.8.8.8 || forward و NAT روی Hub فعال است
| پاسخ از 8.8.8.8 || forward و NAT روی Hub فعال است
|-
| 100% loss ولی ping HUB_TUNNEL_IP OK || تقریباً قطعی مشکل NAT یا FORWARD روی 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 (تست سرعت بین دو سرور) ===
=== Step 4 — Throughput test with iperf3 (تست سرعت بین دو سرور) ===


اندازه‌گیری throughput واقعی تونل؛ برای ارزیابی BBR و تنظیمات TCP مفید است.
 


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


  apt install -y iperf3
  apt install -y iperf3


==== Server on Hub ====
==== Server on Hub ====


  iperf3 -s -B HUB_TUNNEL_IP
  iperf3 -s -B HUB_TUNNEL_IP


'''توضیح:''' iperf3 فقط روی آدرس تونل Hub گوش می‌دهد تا ترافیک تست از WAN عبور نکند.
 


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


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


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


'''توضیح:''' سرعت ارسال از Remote به Hub را در ده ثانیه اندازه می‌گیرد؛ Retr باید نزدیک صفر باشد.


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


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


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


'''توضیح:''' جهت دانلود را تست می‌کند؛ بدون BBR معمولاً کندتر از آپلود است.


==== Parallel streams ====
==== Parallel streams ====


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


'''توضیح:''' چهار اتصال همزمان throughput کل تونل را بهتر نشان می‌دهد.
 


{| class="wikitable"
{| class="wikitable"
|-
! شاخص !! مقدار قابل قبول (تقریبی) !! تفسیر
|-
|-
! شاخص !! مقدار قابل قبول (تقریبی)
 
| Throughput || صدها Mbps تا نزدیک 1 Gbps || بسته به لینک فیزیکی دو سرور
 
|-
|-
| Throughput || صدها Mbps بسته به لینک
 
| Retr (retransmits) || نزدیک 0 || بالا = MTU، congestion، یا نیاز به BBR
 
|-
|-
| Retr || نزدیک 0 — بالا یعنی ازدحام یا MTU
 
| -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 — Live packet capture (tcpdump روی تونل) ===
 
 
=== Step 5 — tcpdump on tunnel interface (مشاهده ترافیک زنده) ===
 
 
 
==== Install ====
 
 
 
apt install -y tcpdump
 
 
 
==== Capture ====
 
 


  tcpdump -ni l2tpeth0 host REMOTE_TUNNEL_IP
  tcpdump -ni l2tpeth0 host REMOTE_TUNNEL_IP


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


'''توضیح:''' هنگام اتصال کلاینت x-ui یا <code>curl --interface l2tpeth0</code> باید پکت با source <code>REMOTE_TUNNEL_IP</code> دیده شود.
 
'''اجرا روی:''' Remote — هنگام اتصال کلاینت 3x-ui یا اجرای <code>curl --interface l2tpeth0</code>
 
 


{| class="wikitable"
{| class="wikitable"
|-
|-
! مشاهده !! معنی
! مشاهده !! معنی
|-
| پکت‌های <code>REMOTE_TUNNEL_IP →</code> IP خارجی || outbound از تونل فعال است (x-ui یا curl)
|-
|-
| پکت REMOTE_TUNNEL_IP → اینترنت || outbound از تونل فعال است
 
| پکت‌های <code>→ REMOTE_TUNNEL_IP</code> || مسیر برگشت و NAT Hub سالم است
 
|-
|-
| هیچ پکتی || routing rule یا inboundTag در x-ui اشتباه است
 
| 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 (عیب‌یابی برقراری تونل) ===
=== Step 6 — L2TP protocol 115 capture (عیب‌یابی برقراری تونل) ===


وقتی اینترفیس <code>l2tpeth</code> ساخته می‌شود ولی DOWN است یا ping صفر است.
 


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


  ip route get 1.1.1.1
  ip route get 1.1.1.1


مقدار بعد از <code>dev</code> را در دستورات زیر جایگزین کنید.
 


==== On Hub ====
==== On Hub ====


  tcpdump -ni WAN_INTERFACE_HUB host REMOTE_PUBLIC_IP and proto 115
  tcpdump -ni WAN_INTERFACE_HUB host REMOTE_PUBLIC_IP and proto 115


'''توضیح:''' پکت‌های L2TPv3 با encapsulation IP بین Hub و Remote را روی WAN Hub نمایش می‌دهد.
 


==== On Remote ====
==== On Remote ====


  tcpdump -ni WAN_INTERFACE_REMOTE host HUB_PUBLIC_IP and proto 115
  tcpdump -ni WAN_INTERFACE_REMOTE host HUB_PUBLIC_IP and proto 115


'''توضیح:''' نام اینترفیس WAN روی Remote ممکن است <code>eth0</code>، <code>ens160</code> یا غیره باشد.


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


  systemctl restart ql2tpd
  systemctl restart ql2tpd


'''توضیح:''' اگر هیچ پکت 115 دیده نشد، فایروال datacenter پروتکل 115 را بلاک می‌کند.
 
 
{| 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 — Quick checklist policy routing (Remote) ===
 
 
=== Step 7 — Policy routing checklist (Remote) ===
 
 


  ip rule show | grep REMOTE_TUNNEL_IP
  ip rule show | grep REMOTE_TUNNEL_IP
  ip route show table 100
  ip route show table 100
  ip -br addr show l2tpeth0
  ip -br addr show l2tpeth0


'''توضیح:''' بدون rule <code>from REMOTE_TUNNEL_IP lookup 100</code> و default در table 100، x-ui outbound کار نمی‌کند.
 
 
{| 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 — Quick checklist NAT on Hub ===
 
 
=== Step 8 — NAT and forward checklist (Hub) ===
 
 


  sysctl net.ipv4.ip_forward
  sysctl net.ipv4.ip_forward
  iptables -t nat -L POSTROUTING -n -v | grep 10.0.1
  iptables -t nat -L POSTROUTING -n -v | grep 10.0.1
  iptables -L FORWARD -n -v | grep l2tpeth1
  iptables -L FORWARD -n -v | grep l2tpeth1


'''توضیح:''' <code>ip_forward=1</code> و MASQUERADE برای subnet تونل Remote الزامی است.
 
 
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 (جدول خلاصه) ===
=== Expected results summary (جدول خلاصه) ===


{| class="wikitable"
{| class="wikitable"
|-
|-
! Test !! Server !! Expected on success
! Test !! Server !! Expected on success
|-
|-
| ping HUB_TUNNEL_IP || Remote || 0% packet loss
| ping HUB_TUNNEL_IP || Remote || 0% packet loss
|-
|-
| ping REMOTE_TUNNEL_IP || Hub || 0% packet loss
| ping REMOTE_TUNNEL_IP || Hub || 0% packet loss
|-
|-
| curl (no interface) || Remote || REMOTE_PUBLIC_IP
| curl (no interface) || Remote || REMOTE_PUBLIC_IP
|-
|-
| curl --interface l2tpeth0 || Remote || HUB_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
| ping -I l2tpeth0 8.8.8.8 || Remote || 0% packet loss
|-
| iperf3 upload || Remote || high Mbps, low Retr
|-
|-
| iperf3 -c HUB_TUNNEL_IP -B REMOTE_TUNNEL_IP || Remote || high throughput, low Retr
 
| iperf3 -R download || Remote || high Mbps, low Retr (با BBR)
 
|-
|-
| Client IP (x-ui via l2tp-out) || Client || HUB_PUBLIC_IP
 
| tcpdump l2tpeth0 || Remote || پکت REMOTE_TUNNEL_IP هنگام کلاینت
 
|-
 
| Client IP (x-ui) || Client || HUB_PUBLIC_IP
 
|}
|}


----
----


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


{| class="wikitable"
{| class="wikitable"
|-
|-
! Placeholder !! توضیح !! مثال (فقط در استقرار خودتان)
 
! Placeholder !! توضیح !! مثال subnet (غیر عمومی)
 
|-
|-
| <code>HUB_PUBLIC_IP</code> || IP عمومی سرور Hub || —
| <code>HUB_PUBLIC_IP</code> || IP عمومی سرور Hub || —
|-
|-
| <code>REMOTE_PUBLIC_IP</code> || IP عمومی سرور Remote || —
| <code>REMOTE_PUBLIC_IP</code> || IP عمومی سرور Remote || —
|-
|-
| <code>HUB_TUNNEL_IP</code> || IP تونل روی Hub || 10.0.1.1
| <code>HUB_TUNNEL_IP</code> || IP تونل روی Hub || 10.0.1.1
|-
|-
| <code>REMOTE_TUNNEL_IP</code> || IP تونل روی Remote || 10.0.1.2
| <code>REMOTE_TUNNEL_IP</code> || IP تونل روی Remote || 10.0.1.2
|-
|-
| <code>WAN_INTERFACE_HUB</code> || اینترفیس WAN Hub || eth0
| <code>WAN_INTERFACE_HUB</code> || اینترفیس WAN Hub || eth0
|-
|-
| <code>WAN_INTERFACE_REMOTE</code> || اینترفیس WAN Remote || ens160
| <code>WAN_INTERFACE_REMOTE</code> || اینترفیس WAN Remote || ens160
|}
|}


----
----


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


# Ping tunnel endpoints (Step 1)
 
# curl IP test (Step 2)
 
# ping 8.8.8.8 via tunnel (Step 3)
# Prerequisites و نصب iperf3/tcpdump
# iperf3 throughput (Step 4) — optional for quality
 
# tcpdump — if x-ui issue (Step 5)
# 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:L2TPv3]]
[[Category:Ubuntu]]
[[Category:Ubuntu]]
[[Category:Networking]]
[[Category:Networking]]
[[Category:Testing]]

Revision as of 16:30, 6 July 2026

Mikrotik Ubuntu L2TPv3 — Testing Hub and Remote Ubuntu

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


مرتبط: Mikrotik_Ubuntu_L2TPv3



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

نقش Public IP (placeholder) Tunnel IP (placeholder) Interface
Hub HUB_PUBLIC_IP HUB_TUNNEL_IP/30 l2tpeth1
Remote REMOTE_PUBLIC_IP REMOTE_TUNNEL_IP/30 l2tpeth0


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


  • HUB_TUNNEL_IP = 10.0.1.1
  • REMOTE_TUNNEL_IP = 10.0.1.2
  • Subnet NAT روی Hub: 10.0.1.0/30



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

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


  • سرویس ql2tpd روی هر دو سرور در وضعیت active (running) باشد
  • اینترفیس تونل IP داشته باشد: Hub روی l2tpeth1، Remote روی l2tpeth0
  • روی Hub قوانین NAT و FORWARD برای subnet تونل Remote اعمال شده باشد
  • روی Remote policy routing با from REMOTE_TUNNEL_IP lookup 100 فعال باشد
  • ابزارهای تست: curl، iperf3، tcpdump (در صورت نبود: apt install -y iperf3 tcpdump)
  • برای تست IP عمومی از سرویس قابل دسترس در شبکه خودتان استفاده کنید (مثال: https://api.ipnote.ir/myip) — در ایران از سرویس‌های فیلترنشده استفاده کنید


توضیح پیش‌نیاز (۱۰۰+ کلمه):


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


نتیجه تفسیر
0% packet loss تونل برقرار است — به مرحله بعد بروید
100% packet loss ql2tpd، فایروال proto 115، IP اینترفیس یا peer down را بررسی کنید


توضیح (۱۰۰+ کلمه):


دستور ping بین HUB_TUNNEL_IP و REMOTE_TUNNEL_IP مستقیماً روی subnet تونل اجرا می‌شود و نیازی به NAT روی Hub ندارد. اگر این تست موفق باشد یعنی session L2TPv3 برقرار شده، اینترفیس‌های l2tpeth0 و l2tpeth1 آدرس گرفته‌اند و بسته 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"


خروجی curl معنی
REMOTE_PUBLIC_IP ترافیک از WAN مستقیم خارج شده
HUB_PUBLIC_IP ترافیک از تونل و NAT Hub خارج شده
timeout / خطا policy routing Remote یا NAT Hub ناقص است


توضیح (۱۰۰+ کلمه):


این تست مهم‌ترین معیار selective routing روی سرور Remote است. دستور اول بدون bind به اینترفیس تونل اجرا می‌شود و باید IP عمومی خود Remote را نشان دهد؛ این تأیید می‌کند سرور به‌طور عادی به اینترنت دسترسی دارد. دستور دوم با --interface l2tpeth0 اجبار می‌کند اتصال HTTPS از اینترفیس تونل برود؛ در این حالت kernel باید source address برابر REMOTE_TUNNEL_IP انتخاب کند و با rule from REMOTE_TUNNEL_IP lookup 100 بسته از Hub NAT شده و با IP HUB_PUBLIC_IP به اینترنت برود. اگر خروجی دوم HUB_PUBLIC_IP نیست، یا 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"


فیلد معنی اگر زیاد باشد
time_namelookup زمان DNS resolve DNS کند یا فیلتر — rule DNS در x-ui را چک کنید
time_connect زمان TCP connect مسیر تونل یا RTT بالا
time_appconnect پایان TLS handshake latency مسیر Hub
time_total کل درخواست معمولاً ۰.۴ تا ۱ ثانیه از تونل طبیعی است


توضیح (۱۰۰+ کلمه):


این تست به شما کمک می‌کند «کندی» را از «خرابی» جدا کنید. وقتی time_namelookup زیر چند میلی‌ثانیه است، DNS مقصر کندی نیست. تفاوت time_total بین مسیر مستقیم (مثلاً ۰.۰۶ ثانیه) و مسیر تونل (مثلاً ۰.۴۷ ثانیه) به‌خاطر bug نیست؛ ترافیک از Hub در کشور دیگر خارج می‌شود و یک hop و RTT اضافه دارد. این trade-off عمدی selective routing است: IP خروجی HUB_PUBLIC_IP با هزینه latency بیشتر. توجه کنید curl --interface فقط اتصال 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


نتیجه تفسیر
پاسخ از 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 به HUB_TUNNEL_IP که فقط داخل subnet تونل است، این تست بسته ICMP را با source REMOTE_TUNNEL_IP به آدرس اینترنتی (مثلاً 8.8.8.8) می‌فرستد. بسته از تونل به Hub می‌رسد، Hub باید آن را forward کند، NAT (MASQUERADE) بزند و از WAN خارج کند؛ پاسخ ICMP باید برگردد و دوباره از تونل به Remote برسد. اگر Step 1 موفق و این تست ۱۰۰٪ loss است، تقریباً همیشه مشکل روی Hub است: net.ipv4.ip_forward=0، نبود rule MASQUERADE برای subnet تونل، یا FORWARD بین l2tpeth1 و WAN_INTERFACE_HUB بسته است. گاهی rp_filter 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


شاخص مقدار قابل قبول (تقریبی) تفسیر
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 و فقط روی HUB_TUNNEL_IP bind شود تا ترافیک تست از WAN عبور نکند. کلاینت روی Remote با -B REMOTE_TUNNEL_IP اطمینان می‌دهد تمام جریان از policy table 100 و تونل می‌رود. تست بدون -R جهت Upload (Remote به Hub) را می‌سنجد؛ با -R Hub ارسال می‌کند و جهت Download را می‌سنجد — در تونل‌های با RTT بالا بدون BBR ممکن است Download کندتر باشد. -P 4 چهار 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 یا اجرای curl --interface l2tpeth0


مشاهده معنی
پکت‌های REMOTE_TUNNEL_IP → IP خارجی outbound از تونل فعال است (x-ui یا curl)
پکت‌های → REMOTE_TUNNEL_IP مسیر برگشت و NAT Hub سالم است
TCP 443 با تبادل داده اتصال واقعی برقرار — Telegram، Google، Microsoft و غیره
UDP پورت 3478 STUN/WebRTC (تماس ویدیو) از تونل — طبیعی
هیچ پکتی هنگام استفاده کلاینت inboundTag یا routing rule در 3x-ui اشتباه است
ARP از HUB_TUNNEL_IP همسایگی لایه ۲ روی pseudowire — طبیعی


توضیح (۱۰۰+ کلمه):


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


مشاهده تفسیر
پکت proto 115 دوطرفه L2TP در حال مذاکره — اگر l2tpeth DOWN است config ID را چک کنید
هیچ پکت 115 فایروال ufw، iptables، یا cloud firewall پروتکل 115 را بلاک می‌کند
فقط یک طرف فایروال یک‌طرفه یا asymmetric routing


توضیح (۱۰۰+ کلمه):


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



Step 7 — Policy routing checklist (Remote)

ip rule show | grep REMOTE_TUNNEL_IP

ip route show table 100

ip -br addr show l2tpeth0


خروجی مورد انتظار اگر نیست
from REMOTE_TUNNEL_IP lookup 100 ip rule add from REMOTE_TUNNEL_IP lookup 100 priority 100
default via HUB_TUNNEL_IP dev l2tpeth0 در table 100 route default را در table 100 اضافه کنید
REMOTE_TUNNEL_IP/30 روی l2tpeth0 IP و ip link set l2tpeth0 up


توضیح (۱۰۰+ کلمه):


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


خروجی مورد انتظار اگر نیست
ip_forward = 1 sysctl -w net.ipv4.ip_forward=1 و فایل 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) از l2tpeth1 وارد Hub می‌شود و مقصدش اینترنت است، kernel باید forwarding فعال داشته باشد و iptables آن را NAT کند تا مقصد پاسخ را به IP عمومی Hub بفرستد و Hub بتواند پاسخ را به تونل برگرداند. فقط NAT برای subnet تونل Remote اعمال کنید — تونل‌های MikroTik ممکن است مسیر خودشان را داشته باشند. IFACE در دستورات iptables باید اینترفیس WAN واقعی Hub باشد (از ip route get 1.1.1.1). پس از تنظیم، netfilter-persistent save بزنید. MSS clamp روی FORWARD TCP توصیه می‌شود تا با MTU 1400 تونل سازگار باشد. بدون این بخش، ping به HUB_TUNNEL_IP 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 (ترتیب مهم)

  1. inbound مشخص → l2tp-out
  1. port 53 udp,tcp → l2tp-out
  1. بقیه → direct


توضیح (۱۰۰+ کلمه):


اگر تست‌های OS (curl با interface، iperf، tcpdump) موفق هستند ولی تجربه کاربر نهایی بد است، تمرکز روی 3x-ui است. outbound l2tp-out باید protocol freedom با sendThrough برابر 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 باید HUB_PUBLIC_IP باشد. latency حدود نیم ثانیه برای اولین HTTPS از تونل طبیعی است و با iperf 900 Mbps تناقض ندارد.



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

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


توضیح (۱۰۰+ کلمه):


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



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

علامت احتمال اول اقدام
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 (جدول خلاصه)

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 (جدول جایگزین‌ها)

Placeholder توضیح مثال subnet (غیر عمومی)
HUB_PUBLIC_IP IP عمومی سرور Hub —
REMOTE_PUBLIC_IP IP عمومی سرور Remote —
HUB_TUNNEL_IP IP تونل روی Hub 10.0.1.1
REMOTE_TUNNEL_IP IP تونل روی Remote 10.0.1.2
WAN_INTERFACE_HUB اینترفیس WAN Hub eth0
WAN_INTERFACE_REMOTE اینترفیس WAN Remote ens160



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

  1. Prerequisites و نصب iperf3/tcpdump
  1. Step 1 — ping تونل دوطرفه
  1. Step 2 — curl IP مستقیم vs تونل
  1. Step 2b — curl timing (اختیاری — تفکیک کندی)
  1. Step 3 — ping 8.8.8.8 از تونل
  1. Step 8 — اگر Step 3 fail
  1. Step 7 — اگر Step 2 interface fail
  1. Step 4 — iperf3 throughput
  1. Step 10 — BBR اگر -R کند است
  1. Step 5 — tcpdump هنگام کلاینت 3x-ui
  1. Step 9 — تنظیم و تأیید پنل
  1. Step 6 — فقط اگر تونل اصلاً up نمی‌شود


Retrieved from "https://wiki.alikaravi.ir/index.php?title=Ubuntu_To_Ubuntu_Connection_Test&oldid=178"