NAT متقارن و VPN: نگاشت را بسنجید، نه برچسب را
نگاشت وابسته به نقطهٔ پایانی بر کشف همتاها اثر می‌گذارد، نه بر تونل معمول کارخواه به کارساز. پورت را اندازه بگیرید و اگر مسیر مستقیم شکست خورد از بازپخش‌گر استفاده کنید.
یک رشتهٔ پشتیبانی با حکم «NAT متقارن، VPN اینجا کار نمی‌کند» تمام می‌شود و سپس کارخواه سه بار بی‌دلیل دوباره نصب می‌شود. برچسب آسیب می‌زند چون به پرسشی پاسخ می‌دهد که هیچ‌کس نپرسیده است. کارخواهی که به بیرون و به کارسازی ثابت وصل می‌شود، همان لحظه‌ای که نخستین بسته را می‌فرستد یک نگاشت می‌سازد، و پاسخ با قواعدی که تقریباً هر شبکه پیاده می‌کند بازمی‌گردد. چیزی که نگاشت وابسته به نقطهٔ پایانی واقعاً پیچیده می‌کند تلاش دو همتا برای رسیدن هم‌زمان به یکدیگر است، و آن آزمون دیگری است.
دو پرسش پشت یک برچسب پنهان است
پرسش نخست این است که آیا میزبانِ پشت این شبکه می‌تواند نشستی به یک نشانی عمومی و پورت شناخته‌شده باز کند. برای کارخواه تونل این حالت عادی است و پاسخ تقریباً همیشه بله است. مسیریاب منبع درونی را ثبت می‌کند، یک پورت بیرونی تخصیص می‌دهد و پاسخ را عبور می‌دهد چون به نشستی تعلق دارد که از درون آغاز شده است.
پرسش دوم این است که آیا دو میزبان پشت شبکه‌های متفاوت می‌توانند مسیر مشترکی پیدا کنند و بدون کارساز در میانه به هم بفرستند. این به شیوهٔ تخصیص آن پورت‌های بیرونی توسط هر شبکه بستگی دارد و تنها جایی است که رفتار نگاشت اهمیت دارد.
اشتباه گرفتن این دو، همان تشخیص نادرست کلاسیک را می‌سازد: یک ویژگی همتا به همتا شکست می‌خورد، کسی آزمون نوع NAT را اجرا می‌کند، بدترین دسته را می‌بیند و نتیجه می‌گیرد تونل معمولی هم نمی‌تواند کار کند. تونل هرگز چیزی نبود که شکست خورد.
نگاشت و پالایش دو ویژگی جداگانه‌اند
اصطلاح‌شناسی RFC از نام‌هایی که فروشندگان به کار می‌برند دقیق‌تر است و ارزش دارد در تیکت آورده شود چون بحث‌ها را فیصله می‌دهد. نگاشت یعنی پورت بیرونی چگونه تخصیص می‌یابد. پالایش یعنی کدام بسته‌های ورودی اجازهٔ عبور دارند. یک شبکه می‌تواند در یکی سخت‌گیر و در دیگری آسان‌گیر باشد و همان ترکیب چیزی است که یک پروتکل همتا به همتا باید از سر بگذراند.
| Behaviour | What it means | Effect on a direct peer path |
|---|---|---|
| Endpoint-independent mapping | One external port for every destination | Discovery works if the port is advertised |
| Address-dependent mapping | New port per remote address | Works only if both sides probe the same pair |
| Address-and-port-dependent | New port per remote address and port | Usually needs a relay |
سطر سوم همان چیزی است که بیشتر مسیریاب‌های خانگی و اپراتورهای تلفن همراه از واژهٔ متقارن می‌فهمند. توجه کنید که برچسب فقط تخصیص را توصیف می‌کند. شبکه‌ای با آن نگاشت و پالایش آسان‌گیر هنوز می‌تواند بسته‌های ورودی به پورتی را که همین حالا تخصیص داده بپذیرد، و به همین دلیل سوراخ‌کاری روی برخی از آن‌ها موفق می‌شود و روی برخی دیگر نه.
پالایش سه حالت خودش و برای هرکدام نام خودش را دارد. نوشتن «NAT متقارن» در یک تیکت وقتی منظور «پالایش وابسته به نشانی و پورت» است، نفر بعدی را به فصل اشتباه دفترچه راهنما می‌فرستد. این دو در آزمون رفتار متفاوتی دارند، پس خطا دانشگاهی نیست.
نگاشت را بسنجید به‌جای نام‌گذاری آن
می‌توانید پورت تخصیص‌یافته را مستقیماً از سمت کارساز هر سرویس UDP که کنترل می‌کنید مشاهده کنید. روی میزبان عمومی ضبط را آغاز کنید، از کارخواه بفرستید و پورت مبدأیی را که بسته با آن رسیده بخوانید:
sudo tcpdump -ni eth0 -c 10 'udp port 51820'
sudo wg show wg0 endpoints
sudo conntrack -L -p udp --dport 51820سطر نقطهٔ پایانی از آن سه سودمندترین است، چون WireGuard آخرین نشانی و پورتی را که از هر همتا گرفته ثبت می‌کند. آن پورت را با پورتی که کارخواه فکر می‌کند استفاده می‌کند مقایسه کنید. هر زمان ترجمه‌ای رخ دهد متفاوت خواهند بود، و پرسش مهم این است که آیا مقدار پایدار می‌ماند.
مشاهده را در برابر پورت مقصد دوم یا کارساز دوم تکرار کنید و دوباره مقایسه کنید. اگر پورت بیرونی به‌ازای هر مقصد تغییر کند، نگاشت وابسته به نشانی و پورت است. اگر یکسان بماند، شبکه یک نگاشت به شما می‌دهد و کشف شانس دارد.
ابزارهای مبتنی بر STUN همان طبقه‌بندی را در یک گام گزارش می‌کنند و استفاده از آن‌ها وقتی شبکه UDP خروجی به یک کارساز عمومی STUN را مجاز می‌داند بی‌اشکال است. وقتی مجاز نمی‌داند، روش ضبط بالا هنوز کار می‌کند و چیزی جز میزبانی که از قبل کنترل می‌کنید نمی‌خواهد.
اصلاحی هم‌خوان با شکست برگزینید
اگر ویژگی شکست‌خورده همتا به همتاست، پاسخ‌های پشتیبانی‌شده یک بازپخش‌گر، یک سرویس دیدار که هر دو همتا به آن برسند، یا توپولوژی متفاوت است. TURN دقیقاً برای همین وجود دارد و محصولی که بازپخش‌گر خودش را عرضه می‌کند به شما می‌گوید انتظار دارد برخی شبکه‌ها خصمانه باشند.
اگر ویژگی شکست‌خورده یک تونل معمولی است، رفتار نگاشت مشکل شما نیست و هیچ‌یک از موارد بالا اعمال نمی‌شود. بررسی کنید که کارخواه واقعاً می‌فرستد، کارساز بسته را می‌بیند و پاسخ بازمی‌گردد. آن توالی سه مشاهده است و هیچ دانستنی دربارهٔ دستهٔ NAT مسیریاب لازم ندارد.
چیزی که کار نمی‌کند پخش کردن تغییرات پورت محلی تا وقتی چیزی وصل شود است. تغییر پورت مبدأ کارخواه تغییری در شیوهٔ تخصیص نگاشت‌ها توسط شبکه نمی‌دهد. موفقیت تصادفی در تلاش پنجم یک مثبت کاذب است و ماه‌ها به‌عنوان راه‌حل نقل می‌شود.
معماری را ثبت کنید، نه حکم را
یک یادداشت سودمند می‌گوید کدام پروتکل، نشست در کدام جهت آغاز می‌شود، آیا بازپخش‌گری در مسیر هست و روی سیم چه مشاهده شده است. «NAT متقارن، کار نمی‌کند» بی‌فایده است، چون هم‌زمان دربارهٔ تونل نادرست است و دربارهٔ مسیر همتا چیزی نمی‌گوید.
اگر آزموده‌اید، پایداری اندازه‌گیری‌شدهٔ پورت و رفتار پالایش را هم بیاورید. این دو واقعیت به دیگری امکان می‌دهد پیش‌بینی کند آیا ویژگی تازه‌ای در آن شبکه کار می‌کند، بدون تکرار تمام بررسی. همچنین بهتر از دستهٔ فروشنده‌ای که در هر صفحهٔ راهنما معنایی کمی متفاوت دارد، کهنه می‌شوند.
در پایان، هنگام نوشتن اصطلاح‌شناسی RFC 4787 را در دسترس داشته باشید. به‌کار بردن اصطلاحات دقیق یک جمله هزینه دارد و مانع می‌شود خوانندهٔ بعدی همان تشخیص نادرست را تکرار کند، و تمام هدف نوشتن یادداشت همین است.