NAT سنجاقی: چرا نقطه پایانی VPN از داخل کار نمیکند
کارخواه محلی که از نشانی عمومی استفاده میکند از LAN خارج میشود و دوباره برمیگردد. وقتی مسیریاب hairpin انجام نمیدهد، از بیرون کار میکند و از داخل نه.
کارساز VPN که از شبکه همراه پاسخ میدهد و از روی مبل کار نمیکند معمولاً مشکل گواهی نیست. کارخواه داخل LAN از مسیریاب میخواهد بستهای را ترجمه کند که مقصدش نشانی عمومی خود مسیریاب است، یعنی بسته باید خارج شود و بیدرنگ برگردد. این مانور hairpinning نام دارد و بسیاری از مسیریابها یا آن را پیاده نمیکنند یا فقط وقتی کادر تأییدی فعال باشد انجامش میدهند. موفقیت آزمون بیرونی همان چیزی است که ماجرا را گیجکننده میکند، چون ثابت میکند شنونده و قاعده ارسال درستاند.
بسته خارج میشود و برمیگردد
بسته را دنبال کنید. کارخواه نام عمومی را باز میکند، به نشانی عمومی وصل میشود و NAT مقصد در مسیریاب مقصد را به کارساز داخلی بازنویسی میکند. پاسخ کارساز به نشانی LAN کارخواه نشانهگذاری شده است، پس از طریق واسط LAN مسیریاب برمیگردد بدون اینکه هرگز از قاعده NAT عبور کند که میتوانست مبدأ را بازگرداند.
اکنون کارخواه بستهای از نشانی دریافت میکند که هرگز چیزی به آن نفرستاده و آن را دور میریزد. همین ناهمسانی تمام خرابی است.
RFC 4787 رفتاری را توصیف میکند که در این حالت از NAT انتظار میرود، و نسخه کوتاه این است که در عمل اختیاری است حتی جایی که در نظریه مشخص شده است. برخی مسیریابها این تنظیم را NAT loopback مینامند، برخی hairpin NAT یا NAT reflection و برخی هیچ چیز ارائه نمیکنند. مسیریابی که آن را ندارد بدتنظیم نیست؛ کار معمول را انجام میدهد و رفع مشکل جای دیگری است. از شکست یک آزمون محلی نتیجه نگیرید که قاعده ارسال عمومی غلط است.
بررسی 1: دو مسیر را جداگانه بیازمایید
از بیرون LAN با همان نمایهای که کاربر واقعی استفاده میکند وصل شوید و تأیید کنید که نشست برقرار میشود. از داخل با همان نمایه به نشانی عمومی وصل شوید و خطای دقیق و زمان را ثبت کنید.
یک آزمون محلی دقیق نام میزبان را نگه میدارد و فقط نشانی را جایگزین میکند: curl -v --resolve vpn.example.com:443:203.0.113.10 https://vpn.example.com/ درخواست را به نشانی عمومی میفرستد و در همان حال نام درست کارساز را ارائه میدهد. این مشکل بازگشایی نام را از مشکل ترجمه جدا میکند، که وقتی همان نام از یک کافه کار میکند بهآسانی اشتباه گرفته میشوند. توجه کنید که کارخواه در اتصال TCP شکست میخورد یا بعدتر در TLS، چون اولی به ترجمه و دومی به هویت اشاره دارد.
بررسی 2: بخوانید کارساز چه میبیند
سودمندترین مشاهده دیدگاه کارساز است. روی میزبان VPN یک ضبط با پالایه روی نشانی LAN کارخواه و نشانی LAN مسیریاب اجرا کنید، سپس تلاش محلی را تکرار کنید. اگر چیزی نرسد، بسته از ترجمه جان سالم به در نبرده است.
اگر اتصالی از نشانی LAN مسیریاب برسد نه از نشانی کارخواه، hairpinning رخ میدهد و مبدأ بازنویسی شده است. این پیکربندی کارآمد است، نه خرابی.
بررسی 3: بدون دست زدن به مسیر بیرونی درستش کنید
سه شکل پشتیبانیشده وجود دارد، به ترتیب افزایش شعاع اثر. باریکترین DNS تقسیمشده است: یک رکورد داخلی منتشر کنید تا همان نام کارساز برای کارخواههای LAN به نشانی داخلی بازگشایی شود، که مسیر عمومی را کاملاً دور میزند. شکل بعدی فعال کردن گزینه مستند loopback یا reflection مسیریاب است، اگر دارد، و اعمال آن فقط بر این سرویس. گستردهترین یک قاعده source-NAT روی مسیریاب است که ترافیک آمده از LAN را به کارساز بازنویسی میکند تا پاسخ از مسیریاب برگردد؛ روی مسیریاب Linux این قاعده MASQUERADE در POSTROUTING است که با نشانی و درگاه کارساز مطابقت دارد. هر سه مسیر بیرونی را دستنخورده نگه میدارند و همین ویژگی باید حفظ شود.
ارسال درگاه نامرتبط را گسترش ندهید تا مسیر محلی شبیه بیرونی شود، و سرویس را برای دور زدن مشکل به درگاه دیگری منتقل نکنید. هر دو تغییر آنچه را جهان بیرون میتواند برسد تغییر میدهند تا چیزی را درست کنند که فقط جهان درون میبیند.
DNS تقسیمشده یک تله دارد که ارزش نام بردن دارد. جایگزینی نام میزبان با یک IP دلبخواه تغییر میدهد که کارخواه چه چیزی را اعتبارسنجی میکند، پس رکورد داخلی باید هنوز با نام گواهی بخواند.
بررسی 4: پس از آن هر دو مسیر را بررسی کنید
تلاش بیرونی را از بیرون LAN تکرار کنید، تلاش درونی را با همان نمایه تکرار کنید و تأیید کنید که گزارش کارساز دو نشست موفق متمایز نشان میدهد نه یک موفقیت و یک سکوت. سپس بررسی کنید که کارخواههای دیگر هنوز به شنونده میرسند و مسیرهای منابع خصوصی تغییر نکردهاند.
گزارش را کوتاه نگه دارید: هر کارخواه از کدام نشانی استفاده کرد، کارساز چه دید و کدام یک از سه راهحل اعمال شد. الزامات hairpinning در RFC 4787 مرجع آن چیزی است که اینجا از NAT انتظار میرود، و توضیح میدهد چرا مسیریاب بدون این ویژگی بهطور عادی رفتار میکند. شکست محلی که جهان بیرون نمیتواند بازتولید کند تا خلافش ثابت نشود مسئله ترجمه است، پس آن را همینگونه بیازمایید.