چرا کلاینت‌های Access Server از LAN در دسترس نیستند
کلاینت‌های مسیریابی‌شده آدرس استخر را نگه می‌دارند، بنابراین پاسخ‌ها به مسیر بازگشت نیاز دارند. منبع را در سرویس بخوانید و سپس مسیر استخر را روی دروازه درست اضافه کنید.
لپ‌تاپ وصل می‌شود، تونل بالا است و درخواست‌ها به یک سرویس داخلی هنگام اتصال معلق می‌مانند. در خود سرویس، درخواست از آدرسی مانند 10.90.0.25 می‌رسد، پاسخ به سمت دروازه پیش‌فرض خارج می‌شود و چیزی برنمی‌گردد، چون آن دروازه هیچ تصوری ندارد که 10.90.0.25 کجاست. از سمت دیگر، همان خطا مانند یک میزبان داخلی دیده می‌شود که نمی‌تواند به یک کلاینت متصل پینگ بزند. هر دو یک شیء گمشده‌اند: مسیر بازگشت به استخر کلاینت‌های VPN، که فقط شبکه خصوصی می‌تواند آن را اضافه کند.
آدرس مبدأ را که سرویس می‌بیند بخوانید
همین یک فیلد بقیه چیزها را تعیین می‌کند. اگر سرویس داخلی آدرس استخر را می‌بیند، Access Server به‌جای پنهان کردن ترافیک کلاینت مسیریابی می‌کند و هر پاسخ باید به استخر بازگردانده شود. اگر به‌جای آن آدرس خصوصی خود سرور را می‌بیند، سرور ماسک می‌کند و مسیر بازگشت از قبل کار می‌کند، اما به بهای از دست رفتن هویت هر کلاینت در گزارش‌ها و قواعد دسترسی سرویس.
پیش از تغییر هر چیزی هر دو سر را مقایسه کنید. روی سرور، رابط‌های تونل و آدرس‌هایشان را فهرست کنید؛ روی کلاینت، تأیید کنید کدام یک از آن آدرس‌ها را واقعاً دارد؛ روی میزبان داخلی، یک اتصال زنده را ببینید.
ip -br addr show
ss -tnp state established '( dport = :443 )'
ip route get 10.90.0.25دستور آخر همان چیزی است که در حالت خراب شکست می‌خورد: یا پیشوند تونل را غیرقابل‌دسترس گزارش می‌کند یا، بدتر، دروازه پیش‌فرض شما را برمی‌گرداند، و این‌گونه است که پاسخ‌ها به اینترنت می‌رسند.
فرض نکنید فقط یک استخر وجود دارد. یک سرور می‌تواند یک بازه پویا به‌همراه نقشه‌برداری‌های ثابت برای هر کاربر داشته باشد، و آدرس ثابت می‌تواند کاملاً بیرون از پیشوند پویا باشد. اگر فقط بازه‌ای را که به یاد دارید مسیریابی کنید، کاربران با آدرس ثابت خراب می‌مانند و بقیه گزارش می‌دهند که مشکل حل شده است.
مسیر را جایی اضافه کنید که پاسخ تعیین می‌شود
مسیر متعلق به دروازه‌ای است که سرویس داخلی از قبل استفاده می‌کند، نه خود سرویس، مگر اینکه سرویس ترافیک خودش را مسیریابی کند. آن را به آدرس خصوصی قابل‌دسترس Access Server اشاره دهید، که مقداری متفاوت از آدرس تونل کلاینت است.
ip route add 10.90.0.0/24 via 10.0.1.5
ip route get 10.90.0.25در یک شبکه ابری همان جمله به یک ورودی جدول مسیر تبدیل می‌شود که هدفش نمونه یا رابط شبکه‌ای است که سرور روی آن اجرا می‌شود، با غیرفعال بودن بررسی مبدأ و مقصد روی آن رابط. توجه کنید این ورودی چه کاری نمی‌کند: مسیر یک مجوز دسترسی نیست، پس گروه‌های امنیتی، ACLهای شبکه و فایروال میزبان هنوز باید ترافیک را مجاز کنند.
آن را پایدار کنید و اندازه استخرها را صادق نگه دارید. دو استخر ناپیوسته به دو مسیر نیاز دارند، و استخری که از پیشوند پیکربندی‌شده فراتر رشد می‌کند بی‌صدا کلاینت‌هایی می‌سازد که پاسخ‌هایشان جایی برای رفتن ندارند. اگر بازه‌های استخر را کنترل می‌کنید، خلاصه‌ای را انتخاب کنید که یک بار مسیریابی شود و رها شود.
ارسال به جلو و فیلترها باید با مسیر هم‌خوان باشند
مسیریابی فقط نیمی از راه است. سرور باید مجاز باشد بین تونل و رابط خصوصی ارسال به جلو انجام دهد، که در لینوکس یعنی net.ipv4.ip_forward به‌همراه زنجیره‌ای از ارسال به جلو که آن جفت رابط را مجاز می‌کند، و روی میزبان سخت‌شده معمولاً یک قاعده صریح برای هر جهت.
sysctl net.ipv4.ip_forward
nft list ruleset | grep -A5 forwardفیلتر کردن حالت‌دار نشانه‌ای را توضیح می‌دهد که مردم را به راه اشتباه می‌فرستد. پاسخ درون یک جریان برقرارشده به قاعده ورودی جدید نیاز ندارد، پس اتصالی که پس از SYN-ACK معلق می‌ماند توسط قاعده accept گمشده مسدود نمی‌شود؛ بلکه دور ریخته یا بد مسیریابی می‌شود. این تفکیک را نگه دارید، چون تغییر مسیریابی را از تغییر فایروال جدا می‌کند.
مسیرهای بازگشت نامتقارن نسخه آرام‌تر همان مشکل‌اند. اگر دو مسیر به استخر برسند و پاسخ آن را بگیرد که از رابطی متفاوت از رابط ورود درخواست خارج می‌شود، فیلتر سخت‌گیرانه مسیر معکوس آن را دور می‌ریزد و جریان فقط برای بعضی کلاینت‌ها شکست می‌خورد.
مسیریابی‌شده یا ماسک‌شده: آگاهانه انتخاب کنید
حالت مسیریابی‌شده آدرس استخر کلاینت را در سرویس حفظ می‌کند، که ثبت و سیاست هر کلاینت را ممکن می‌سازد، و در عوض هر شبکه داخلی که باید به یک کلاینت پاسخ دهد به مسیر استخر نیاز دارد. حالت ماسک‌شده آن الزام را برمی‌دارد چون پاسخ‌ها به سرور بازمی‌گردند، اما سرویس دیگر نمی‌تواند یک کلاینت را از دیگری تشخیص دهد و نمی‌تواند چیزی به سمت کلاینت مشخصی آغاز کند.
تغییر این رفتار روی سرور زنده نشست‌های موجود را قطع می‌کند، پس ابتدا با یک کلاینت و یک جریان آزمایش کنید. اگر تغییر پاسخ درست است، این تصمیمی در پیکربندی سرور است، نه چیزی که با افزودن مسیرهایی که بعداً غیرضروری می‌شوند دور زده شود.
زیرشبکه پشت کلاینت کاری جداگانه است
رسیدن به دستگاهی در LAN خود لپ‌تاپ با رسیدن به آدرس تونل لپ‌تاپ یکی نیست. نیاز دارد که کلاینت به‌عنوان دروازه زیرشبکه عمل کند: شبکه‌ای اعلام‌شده در سمت کلاینت، ارسال به جلو فعال در سیستم‌عامل کلاینت، و مسیری در آن LAN به سمت کلاینت. افزودن مسیر شبکه خصوصی برای بازه خانگی لپ‌تاپ این کار را نمی‌کند و وقتی دو کاربر بازه خانگی یکسان دارند تعارض ایجاد می‌کند.
جهت هم مسئله سیاست است. اجازه به کلاینت برای باز کردن اتصال به یک سرویس داخلی به‌طور خودکار به میزبان داخلی اجازه نمی‌دهد به آن کلاینت اتصال باز کند. پیش از نتیجه‌گیری که مسیر خراب است، سیاست دسترسی سرور و فایروال میزبان کلاینت را بررسی کنید.
با یک جریان و یک ضبط تأیید کنید
مسیر را با یک اتصال اثبات کنید نه با یک آزمون کلی دسترس‌پذیری. همان جریان را در دو سر تماشا کنید: درخواستی که به سرویس می‌رسد و پاسخی که آن را ترک می‌کند.
tcpdump -ni any host 10.90.0.25 and port 443پیش از اصلاح، ضبط نشان می‌دهد پاسخ به سمت دروازه‌ای می‌رود که آن را مسیریابی نخواهد کرد. بعد از اصلاح، پاسخ به سمت سرور می‌رود و جریان کامل می‌شود. سپس مسیری را که دروازه برای آدرس کلاینت دوم استفاده می‌کرد تأیید کنید، تا استخری که پوشش نداده‌اید همین حالا پیدا شود نه یک هفته بعد.
با چهار بررسی که این را می‌بندند تمام کنید: آدرس مبدأ در سرویس با حالتی که قصد داشتید مطابق است، دروازه به هر استخر در حال استفاده مسیر دارد، ارسال به جلو و فیلترها هر دو جهت را مجاز می‌کنند، و یک جریان واقعی از ابتدا تا انتها کامل می‌شود. پرسش‌های متداول مسیریابی Access Server همان اصل را برای نسخه نصب‌شده بیان می‌کند که رابط پیکربندی پشتیبانی‌شده‌اش ممکن است با راهنماهای قدیمی‌تر تفاوت داشته باشد.