کلاینت VPN را از طریق SSH اجرا می‌کنید؟ اول مسیر خودتان را ثابت کنید

با SSH وارد یک میزبان ساخت می‌شوید، کلاینت VPN را روی آن اجرا می‌کنید و نشست از پاسخ دادن باز می‌ماند. هیچ چیز خراب نشده و هیچ چیز در معنای آشکار بدپیکربندی به نظر نمی‌رسد. کلاینت یک مسیر پیش‌فرض نصب کرد، بنابراین پاسخ‌ها به ایستگاه کاری شما اکنون از تونل خارج می‌شوند، جایی که نشانی ایستگاه کاری شما قابل مسیریابی نیست. بخش جالب این است که این نتیجه قابل پیش‌بینی بود، و راه‌حل یک مسیر است که پیش از شروع کلاینت نوشته می‌شود. فرض کنید سروری با یک کارت شبکه، دروازه‌ای 192.0.2.254 و مدیرى که از 203.0.113.9 متصل می‌شود.

پیش از شروع مسیر را ثبت کنید

ip route show default دروازه و رابط فعلی را نام می‌برد، در حالی که ip route get 203.0.113.9 نشان می‌دهد هسته برای نشست شما از کدام رابط و نشانی مبدأ استفاده می‌کند. هر دو خروجی را نگه دارید. پس از بالا آمدن تونل، این دو فرمان باید همچنان مسیر فیزیکی را توصیف کنند، و اگر به جای آن تونل را توصیف کنند، نشست از پیش روی زمان قرضی زندگی می‌کند.

اتصالی که از قبل برقرار شده همان چیزی است که اهمیت دارد، پس فقط با یک ورود تازه اعتبارسنجی نکنید. یک نشست جدید می‌تواند به‌طور گذرا از طریق حالتی موفق شود که نشست قدیمی دیگر آن را ندارد.

نشانی را در پیکربندی خود کلاینت ثابت کنید

مسیری که دستی اضافه شده با راه‌اندازی مجدد ناپدید می‌شود و با به‌روزرسانی‌های جدول خود کلاینت رقابت می‌کند، پس استثنا را جایی بگذارید که جدول مدیریت می‌شود. در OpenVPN کلیدواژه net_gateway به دروازه‌ای که پیش از تونل وجود داشت حل می‌شود، بنابراین route 203.0.113.9 255.255.255.255 net_gateway دقیقاً یک نشانی را بیرون از آن نگه می‌دارد. WireGuard به رویکرد دیگری نیاز دارد چون wg-quick خودش مسیرها را مدیریت می‌کند: Table = off را تنظیم کنید و استثنا را در PostUp اضافه کنید، همراه با PostDown متناظری که آن را حذف می‌کند. هر دو شکل یک قصد را بیان می‌کنند و هر دو استثنا را به یک نشانی محدود می‌کنند به جای اینکه تونل را برای همه چیز ضعیف کنند.

برای IPv6 همان ایده یک پیشوند تک‌میزبان می‌گیرد، و مورد حمل بسته‌بندی‌شده ارزش به یاد سپردن دارد: اگر اتصال بیرونی خود تونل روی نشانی ثابت زندگی می‌کند، آن نشانی باید بیرون از تونلی بماند که حمل می‌کند، وگرنه کلاینت حمل خودش را به درون خودش مسیریابی می‌کند.

یا جدول اصلی را از معادله بیرون بگذارید

وقتی چندین سرویس روی میزبان باید مسیر عادی خود را حفظ کنند، ویرایش جدول اصلی را متوقف کنید و جدول خودش را به کلاینت بدهید. یک فضای نام شبکه با جفت veth این کار را تمیز انجام می‌دهد: مسیر پیش‌فرض کلاینت در پشته دیگری زندگی می‌کند و تنها فرایندهایی که درون آن شروع می‌شوند از تونل استفاده می‌کنند. مسیریابی سیاستی برای یک مقصد به جای مشابهی می‌رسد، با فرستادن ترافیک منطبق به یک جدول اختصاصی که پیش‌فرض آن هنوز به دروازه فیزیکی اشاره می‌کند. هر یک از این دو رویکرد جدول اصلی میزبان را بدون مسیر پیش‌فرض تازه رها می‌کند، و همین ویژگی است که SSH را پاسخگو نگه می‌دارد.

هر دو ماشین‌آلات بیشتری از یک مسیر میزبان هستند و هر دو زمانی ارزش دارند که بیش از یک چیز روی دستگاه باید از تونل جان سالم به در ببرد.

فرض کنید ثابت‌کردن می‌تواند شکست بخورد

مسیری که به نشانی عمومی فعلی شما گره خورده، همان لحظه‌ای که ارائه‌دهنده شما آن را دوباره تخصیص می‌دهد می‌شکند. آنگاه یک سرور راه دور به مسیری نیاز دارد که به آن نشانی وابسته نباشد: یک کنسول، یک رابط مدیریت دوم، یا یک میزبان پرش که بیرون از تونل می‌ماند.

دو تدبیر حفاظتی ده دقیقه هزینه دارند. نگهبانی که اگر ورود تأییدی در چند دقیقه ظاهر نشود کلاینت را متوقف می‌کند، قفل‌شدن را به تأخیر تبدیل می‌کند، و نشست دوم SSH که در طول تغییر باز نگه داشته می‌شود ثابت می‌کند استثنا زمانی که تونل بالاست کار می‌کند. فقط keepaliveها اینجا کمک نمی‌کنند، چون مسیر رفته است نه بیکار؛ آن‌ها فقط مرگ را آسان‌تر برای توجه کردن می‌کنند.

به همان ترتیبی که اهمیت دارد بررسی کنید

تونل را وصل کنید، تأیید کنید که مسیر به نشانی شما هنوز از دروازه فیزیکی خارج می‌شود، سپس یک نشست تازه باز کنید. اگر نشست تازه کار کند و نشست قدیمی با این حال بمیرد، علت ردیابی اتصال یا فایروال حالت‌مند است نه مسیریابی، که راه‌حل دیگری است.

نشانی ثابت‌شده و فرمانی که آن را اثبات کرد در سابقه تغییرات بنویسید. نفر بعدی که کلاینتی روی آن میزبان اجرا می‌کند به هر دو نیاز خواهد داشت، و ممکن است نشانی تا آن زمان تغییر کرده باشد.