SSH به IP عمومی سرور WireGuard در ویندوز کار نمی‌کند

تونل‌هایی که بالا می‌آیند در حالی که SSH به نشانی عمومی سرور از کار می‌افتد، شبیه سروری به نظر می‌رسند که اتصال را رد می‌کند. در ویندوز علت محتمل‌تر محلی است: AllowedIPs یک تونل کامل با /0 قواعد محدودکننده فایروال را روشن می‌کند که انتقال خود تونل و چیز بسیار کمی جز آن را مجاز می‌کند. بسته‌های رمزنگاری‌شده‌ای که به آن نشانی می‌رسند هیچ چیزی درباره اینکه آیا یک اتصال TCP جداگانه به همان نشانی می‌تواند خارج شود نمی‌گویند.

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

اجازه مسیریابی و اجازه فایروال متفاوت‌اند

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

به همین دلیل یک traceroute به نقطه پایانی می‌تواند موفق شود در حالی که تلاش SSH شکست می‌خورد. اولی را سرویسی می‌برد که استثنا از آن اوست و دومی را نه.

/0 در ویندوز چه می‌کند

وقتی یک همتا نشانی‌های مجازش کل فضای IPv4 را می‌پوشاند، WireGuard for Windows وضعیت محدودکننده فایروال را اعمال می‌کند که ترافیکی را مسدود می‌کند که در غیر این صورت از تونل بیرون می‌رفت. انتقال خود سرویس تونل مجاز است، چون VPN در غیر این صورت نمی‌توانست کار کند. برنامه دیگری به همان نشانی عمومی چنین اجازه‌ای نمی‌گیرد، زیرا استثنا به انتقال تعلق دارد نه به نشانی. یادداشت‌های شبکه ویندوز این رفتار و کنترل مرتبط در ویرایشگر را توصیف می‌کنند.

این قواعد سازوکار پشت عبارت kill switch هستند. آن‌ها با شکل پیکربندی فعال می‌شوند نه با یک کادر تیک که این نام را دارد.

استثناها مدل حفاظت را تغییر می‌دهند

جایگزینی /0 با دو پیشوند نیمه‌پیش‌فرض روش مستندشده برای حفظ مسیریابی گسترده بدون معناشناسی محدودکننده است و مدل حفاظتی متفاوت است نه املای کوتاه‌تر. کم کردن نشانی نقطه پایانی از پیشوندهای مجاز راه‌حل رایج دیگر است که فهرست را طولانی‌تر می‌کند و همچنین تغییر می‌دهد کدام قواعد فعال شوند. هیچ‌کدام ویرایشی محلی با اثر محلی نیست. هرکدام مرز را برای هر جریان روی دستگاه جابه‌جا می‌کند، نه فقط برای اتصالی که در حال تعمیرش بودید.

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

مسیر مدیریتی را که انتخاب کردید آزمایش کنید

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

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

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

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