NAT تعیین می‌کند سرور VPN شما در واقع کدام نشانی مبدأ را می‌بیند
نشانی لپ‌تاپ شما هرگز به سرور VPN نمی‌رسد. NAT آن را در آخرین پرش بازنویسی می‌کند و IP تونل بعداً تخصیص می‌یابد. چگونه دو سر را مقایسه کنید.
تصور می‌کنید سرور VPN نشانی لپ‌تاپ شما را از بسته می‌خواند و در گزارش می‌نویسد. آنچه می‌خواند همان چیزی است که آخرین پرش NAT در سرآیند بیرونی گذاشته است، و روی تلفنی که به‌عنوان نقطه اتصال استفاده می‌شود این معمولاً نشانی‌ای است که با صدها مشترک دیگر مشترک است. نشانی خود دستگاه شما 192.168.x.x هرگز در آن سرآیند از اینترنت عبور نمی‌کند، و نشانی تونل را سرور پس از برقراری اتصال تخصیص می‌دهد. پس وقتی گزارش سرور و ip addr روی لپ‌تاپ با هم نمی‌خوانند، هیچ‌کدام غلط نیست؛ آن‌ها لایه‌های مختلف یک نشست را توصیف می‌کنند.
سه نشانی، و تنها یکی در گزارش است
سردرگمی از ادغام سه نشانی در یکی می‌آید. هر یک مالک متفاوتی دارد، در سرآیند متفاوتی زندگی می‌کند و از مسیر متفاوتی به سرور می‌رسد.
| Address | Who assigns it | Where it sits | Visible to the VPN server |
|---|---|---|---|
Device address, e.g. 192.168.1.24 | Your router via DHCP | Outer header, before translation | No, rewritten in place |
| Translated address and port | Router, ISP CGNAT, or both | Outer header, after translation | Yes, this is the tuple it logs |
Tunnel address, e.g. 10.8.0.6 | The VPN server itself | Inner header, after decapsulation | Yes, but it chose it |
تنها ردیف میانی در زمان اتصال ناشناخته است. سرور آن را بسته به دیمن در جدول همتاها، فایل وضعیت یا گزارش جریان می‌نویسد: WireGuard آن را نقطه پایانی می‌نامد، فایل وضعیت OpenVPN آن را Real Address برچسب می‌زند و strongSwan آن را میزبان راه‌دور IKE_SA گزارش می‌کند. این مقدار هر بار که بسته‌ای از مبدأ متفاوت می‌رسد تازه می‌شود، پس بدون اینکه کسی چیزی را دوباره راه‌اندازی کند تغییر می‌کند.
ردیف پایینی همان چیزی است که مردم به‌اشتباه ادعای هویت می‌خوانند. این یک جایگاه در پیکربندی سرور را نشان می‌دهد، نه یک شخص، زیرا سرور آن را از استخر خودش انتخاب کرده است. دو کاربر می‌توانند در روزهای مختلف همان نشانی تونل را بگیرند، و یک نفر می‌تواند دو تا از آن‌ها را از دو دستگاه داشته باشد.
چرا تاپل ثبت‌شده تغییر می‌کند در حالی که تونل برپاست
ترجمه نشانی جدولی با تایمر است، نه پیوند دائمی. یک روتر خانگی نگاشت UDP خود را مدتی پس از آخرین بسته نگه می‌دارد، دروازه اپراتور پورت‌ها را طبق برنامه خودش بازیافت می‌کند، و تلفنی که از Wi-Fi به LTE می‌رود با مبدأی کاملاً متفاوت برمی‌گردد. مقادیر پیش‌فرض conntrack در لینوکس معیار مفیدی است: nf_conntrack_udp_timeout برابر 30 ثانیه و نسخه استریم 120 است، پس یک تونل ساکت می‌تواند خیلی پیش از آنکه کاربر متوجه شود نگاشت خود را از دست بدهد.
تونل زنده می‌ماند چون پروتکل همتا را احراز هویت می‌کند، نه نشانی را. WireGuard پس از دست‌دادن بی‌حالت است، پس هر بسته احرازشده نقطه پایانی ذخیره‌شده را به‌روز می‌کند و اتصال دوباره با بسته بعدی درمان می‌شود؛ به همین دلیل persistent-keepalive = 25 وجود دارد تا نگاشت را در زمان بی‌کاری گرم نگه دارد. --float در OpenVPN همین کار را می‌کند و به کلاینت احرازشده اجازه می‌دهد از نشانی و پورت جدید ادامه دهد. در بیلدهای 2.4 و 2.5 که float به‌طور پیش‌فرض خاموش است، اتصال دوباره نشست را بازنشانی می‌کند و کلاینت دوباره وصل می‌شود.
IPsec با قطعات متحرک بیشتری به آنجا می‌رسد. IKEv2 ترجمه را با مقایسه هش‌های مبدأ و مقصد در محموله‌های تشخیص NAT متوجه می‌شود، به کپسوله‌سازی UDP 4500 می‌رود و keepaliveها را تا تاپل جدید دنبال می‌کند. وقتی keepaliveها مسدود می‌شوند، SA روی کاغذ برپا می‌ماند در حالی که ترافیک در یک جهت بی‌صدا متوقف می‌شود.
سرور چه چیزی را می‌تواند نسبت دهد و چه چیزی را نه
افسانه‌ای که ارزش کشتن دارد این است که ترجمه شما را از اپراتور پنهان می‌کند. این برچسب را عوض می‌کند، نه مشاهده را. دروازه‌ای پشت NAT اپراتور فضای 100.64.0.0/10 یا یک نشانی عمومی مشترک میان بسیاری از مشترکان را می‌بیند و باز هم می‌تواند جریان را به موضوع گواهی، کلید عمومی WireGuard، نشانی تونل تخصیص‌یافته، شمارنده‌های بایت و یک پنجره زمانی گره بزند. هیچ‌یک از این‌ها به نشانی LAN شما نیاز ندارد.
محدودیت‌ها در جهت دیگر هم عمل می‌کنند. یک نشانی مشترک در گزارش به یک دروازه اشاره دارد، نه به یک خانه؛ دو نشست از همان نشانی ترجمه‌شده روی پورت‌های مختلف دو دستگاه متفاوت‌اند؛ همان نشانی در دو روز مختلف می‌تواند دو مشترک بی‌ربط باشد اگر پورت بازیافت شده باشد. سروری که فقط کلیدهای همتا را ثبت می‌کند بدون پایگاه داده حساب‌ها نمی‌تواند آن را به مشتری نسبت دهد، و سروری که فقط نشانی‌ها را ثبت می‌کند نمی‌تواند لپ‌تاپ را از تلفن پشت همان روتر تشخیص دهد.
به‌جای حدس زدن دو سر را مقایسه کنید
برای روشن شدن آنچه رخ داده، همان اتصال را در یک لحظه در هر دو سر ثبت کنید و تاپل را مقایسه کنید، نه نشانی را. در کلاینت، پیش از هر ترجمه‌ای:
ss -uapn 'dport = :51820'
ip -4 route get 203.0.113.10
wg show wg0 endpointsسپس ورودی ترجمه را روی روتر یا دروازه CGNAT بخوانید، و آنچه در نهایت به سرور می‌رسد:
conntrack -L -p udp --dport 51820
tcpdump -ni eth0 udp port 51820سه الگو بیشتر ناسازگاری‌ها را توضیح می‌دهند. پورت مبدأ در سرور با پورت محلی فرق دارد در حالی که مقصد مطابق است: ترجمه معمولی پورت. نشانی مبدأ در سرور به بلوک ISP تعلق دارد که مال شما نیست: دست‌کم یک لایه NAT اضافه. بسته‌ها پس از دوره بی‌کاری متوقف و با پورت جدید ادامه می‌یابند: نگاشت منقضی شده است، نه خطای مسیریابی. اگر برچسب‌های زمانی بیش از یک یا دو ثانیه فاصله دارند، دو تلاش متفاوت را مقایسه می‌کنید.
کجا تفاوت کارها را خراب می‌کند
قطعی‌هایی که شبیه خطای سرور به نظر می‌رسند معمولاً از اینجا شروع می‌شوند. قاعده دسترسی سنجاق‌شده به نشانی خانه شما پس از تغییر اجاره ISP شکست می‌خورد. قاعده fail2ban که با نشانی ترجمه‌شده مطابقت دارد همه مشترکان پشت آن دروازه را یک‌جا مسدود می‌کند. همتای سایت-به-سایت با نشانی راه‌دور ثابت پس از تغییر پیوند موبایل تازه‌سازی کلید را متوقف می‌کند. پروتکل تونل سالم بود؛ فرض درباره تاپل بیرونی نبود.
همین سردرگمی در سمت سرور هم دیده می‌شود. اگر خود جعبه VPN پشت NAT باشد به هدایت پورت و مسیر ارسال کارآمد نیاز دارید؛ راهنمای ارسال strongSwan این مورد را برای IPsec پوشش می‌دهد. سروری که فقط روی نشانی خصوصی قابل دسترسی است هرگز تاپل ترجمه‌شده‌ای که کلاینت‌هایش ارائه می‌دهند را نمی‌بیند، و این مشکلی متفاوت از ترجمه کلاینت‌هاست.
این چهار بررسی را به ترتیب انجام دهید و در اولین موردی که شکست می‌خورد توقف کنید:
- در هر دو سر هم‌زمان ثبت کنید؛ تأیید کنید که پورت مبدأ، پورت مقصد و برچسب‌های زمانی مطابقت دارند.
- در فهرست همتاهای سرور نشانی‌ای را که اکنون دارد بخوانید، نه نشانی‌ای که انتظار داشتید.
- جدول conntrack یا NAT را برای ورودی و عمر باقی‌مانده آن بررسی کنید.
- تأیید کنید که نشانی رابط تونل در کلاینت با آنچه سرور تخصیص داده مطابقت دارد، نه با نشانی LAN.
اگر هر دو ثبت در تاپل توافق دارند و تونل باز هم شکست می‌خورد، ترجمه مشکل شما نیست؛ به دست‌دادن و جدول مسیریابی داخل تونل بروید.