چرا قاعدهٔ درگاه مبدأ یکی از مسیرهای SSH شما را می‌شکند

دو ورودی مدیریت روی یک میزبان، یک درگاه سرویس، و یک قاعدهٔ سیاست که قرار بود به هر دو کمک کند. قاعده با درگاه مبدأ 22 تطابق می‌یابد، جستجو را به جدولی می‌فرستد که فقط پیش‌فرض WAN را می‌شناسد، و ورودی VPN پاسخ‌دادن به ورودهای جدید را متوقف می‌کند در حالی که ورودی مستقیم همچنان کار می‌کند. وقتی انتخابگر درست خوانده شود، هیچ‌کدام از این‌ها مرموز نیست. درگاه مبدأ یک سرویس را مشخص می‌کند، نه مسیری را که یک اتصال از آن رسیده است.

دو ورودی، یک درگاه سرویس

میزبان یک نشانی سمت LAN و یک نشانی VPN دارد و sshd روی هر دو گوش می‌دهد. بنابراین نشست مستقیم و نشست تونلی درگاه سرویس را شریک می‌شوند و تنها در این تفاوت دارند که کدام نشانی محلی اتصال را دریافت می‌کند.

همین تفاوت برای انتخاب مسیر پاسخ کافی است، و دقیقاً همان تفاوتی است که یک قاعدهٔ مبتنی بر درگاه آن را دور می‌ریزد. هر دو نشست پاسخ‌هایی با درگاه مبدأ 22 تولید می‌کنند، پس قاعده‌ای که با آن درگاه تطابق می‌یابد نمی‌تواند آن‌ها را جدا کند. هر دو جستجو را به یک جدول می‌فرستد و یکی از آن‌ها پاسخی می‌گیرد که جور درنمی‌آید. راه‌حل این است که با ویژگی‌ای تطابق یابد که واقعاً متفاوت است.

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

قاعده را بخوانید، سپس جدول را

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

سپس جدولی را بخوانید که آن قاعده به آن اشاره می‌کند، چون قاعده‌ای که با موفقیت حل می‌شود لزوماً قاعده‌ای نیست که به‌شکلی مفید حل شود. جدولی که فقط مسیر پیش‌فرض را دارد پاسخ منشأگرفته از VPN را از رابط WAN بیرون می‌فرستد. مسیر خاص‌تر در جدول بعدی هرگز بررسی نمی‌شود، و به همین دلیل افزودن جدول دوم اغلب هیچ چیز را تغییر نمی‌دهد. جدول انتخاب‌شده همان چیزی است که باید بررسی شود.

ip -4 rule show
ip route show table 100
ip route show table main

این دو خروجی با هم نتیجه را توضیح می‌دهند؛ هرکدام به‌تنهایی به نتیجه‌گیری نادرست دعوت می‌کند.

قاعده را به جریانی که منظورتان است محدود کنید

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

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

sudo ip rule add from 10.90.0.1 lookup 100 priority 100
sudo ip route add 10.90.0.0/24 dev wg0 table 100
ip route get 10.90.5.20 from 10.90.0.1

اگر هر دو ورودی به یک نشانی محلی ترجمه شوند، آن تمایز از بین می‌رود و طراحی به‌جای آن به حالتی نیاز دارد که از اتصال آگاه باشد.

شنونده، مجوز و انتخاب پاسخ را جدا نگه دارید

پیش از کارکردن یک نشست، سه چیز جداگانه باید درست باشد: نشانی وجود دارد، سرویس روی آن گوش می‌دهد، و پاسخ راه بازگشت را پیدا می‌کند. تغییر مسیر فقط سومی را درست می‌کند.

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

یک کانال بازیابی نگه دارید که به مسیری که تغییر می‌دهید وابسته نباشد، چون خطایی در اینجا خودِ اصلاح را قفل می‌کند.

آن را با یک نشست تازه اثبات کنید، نه با نشست قدیمی

ترمینال برقرارشده چیزی را اثبات نمی‌کند، چون پیش از تغییر پذیرفته شده است. از طریق هر ورودی موردنظر یک نشست تازه باز کنید.

ss -ltnp | grep ':22'
sudo sshd -T | grep -i listenaddress
ssh -v [email protected] true
sudo journalctl -u ssh -n 30

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