SSH до публічної IP сервера WireGuard не працює в Windows

Тунелі, які піднімаються, коли SSH до публічної адреси сервера перестає працювати, виглядають як сервер, що відхиляє з'єднання. У Windows імовірніша причина локальна: AllowedIPs повного тунелю зі значенням /0 вмикає обмежувальні правила брандмауера, які дозволяють власний транспорт тунелю і дуже мало чого іншого. Зашифровані пакети, що доходять до цієї адреси, нічого не кажуть про те, чи може вийти окреме TCP-з'єднання до тієї ж адреси.

Відокремте публічну адресу кінцевої точки від її внутрішньої адреси тунелю, перш ніж торкатися списку вузлів. Майже кожна спроба виправити це редагуванням AllowedIPs робить політику слабшою, а не маршрут правильним.

Дозвіл на маршрутизацію і дозвіл брандмауера — різні речі

Маршрут вирішує, куди буде надіслано пакет, а правило брандмауера — чи можна його надсилати взагалі. Тому додавання маршруту для публічної IP кінцевої точки створює шлях, який фільтр усе ще може заблокувати, і саме цю плутанину породжує цей симптом. У Windows фільтр є частиною реалізації, а не надбудовою, тому жоден запис маршруту його не змінює. Ці два рішення роздільні й в інших місцях, хоч значення за замовчуванням різняться.

Тому traceroute до кінцевої точки може вдатися, тоді як спроба SSH зазнає невдачі. Перше несе служба, якій належить виняток, друге — ні.

Що робить /0 у Windows

Коли в єдиного вузла дозволені адреси охоплюють увесь простір IPv4, WireGuard for Windows застосовує обмежувальну позицію брандмауера, яка блокує трафік, що інакше вийшов би за межі тунелю. Власний транспорт служби тунелю дозволено, бо інакше VPN не міг би працювати. Інша програма до тієї ж публічної адреси такого дозволу не отримує, оскільки виняток стосується транспорту, а не адреси. Нотатки про мережу Windows описують цю поведінку та відповідний елемент керування в редакторі.

Ці правила — механізм, що стоїть за виразом kill switch. Вони вмикаються формою конфігурації, а не прапорцем із такою назвою.

Винятки змінюють модель захисту

Заміна /0 двома напівтиповими префіксами — задокументований спосіб зберегти широку маршрутизацію без обмежувальної семантики, і це інша модель захисту, а не коротший запис. Віднімання адреси кінцевої точки від дозволених префіксів — інший поширений обхід, який подовжує список і також змінює, які правила вмикаються. Жодне з них не є локальною правкою з локальним ефектом. Кожне зсуває межу для кожного потоку на машині, а не лише для з'єднання, яке ви ремонтували.

Там, де прямий публічний SSH справді потрібен, власник профілю має спроєктувати і зовнішній маршрут, і його дозвіл у брандмауері, та вирішити, що станеться з не пов'язаним трафіком, коли тунель упаде. Окремий розгляд IPv4 та IPv6 теж до цього належить, бо правила виражаються за родинами. Широкий обхід, доданий заради порятунку одного сеансу керування, зазвичай розкриває більше, ніж цей сеанс.

Перевірте обраний шлях керування

Спочатку вирішіть, чи керування має йти всередині тунелю чи поза ним, а потім перевірте саме цей вибір, а не обидва одразу. Наведені нижче команди перевіряють адреси клієнта, стан вузла й з'єднання з кожною ціллю. Запускайте їх із клієнта Windows, доки тунель піднято.

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

Успішний SSH до внутрішньої адреси доводить, що тунель несе трафік керування і що власний брандмауер сервера приймає його з діапазону вузлів. Невдача на обох цілях — це проблема на боці сервера або з ключем, а не проблема маршрутизації Windows. Якщо внутрішня адреса працює, а зовнішня ні, локальна позиція брандмауера робить саме те, для чого її створено. Прочитайте три результати в цьому порядку, перш ніж редагувати профіль.

Запишіть шлях керування, використану адресу та поведінку, коли тунель опущено. Саме ця нотатка не дає наступній людині розширити обхід, щоб зекономити п'ять хвилин.