Ръкостискането на WireGuard работи, услугата — не

Ръкостискането завършва, клиентът показва скорошен брояч на трансфера, а заявка към услуга на същия сървър все още се проваля. Тази комбинация обърква хората, защото тунелът очевидно работи. Недоказано остава локалното доставяне: пакетът е стигнал до хоста, а хостът все още трябва да го приеме на правилния сокет и да го предаде на процес с право да отговори. Проверете тези три контролни точки по ред.

Спрете на първата, която не е изпълнена, и не добавяйте правила за останалите.

Ръкостискането доказва само тунела

Ръкостискането на WireGuard установява ключове между партньорите и разрешава трафик за диапазоните, които всеки партньор е изброил. То не казва нищо за това кои процеси слушат на сървъра, нито дали защитната стена на хоста приема пакети, адресирани до един от собствените му адреси.

Именно последното разграничение се пропуска най-често: трафикът към самия хост е локален вход, докато трафикът, преминаващ през хоста към друго място, е препращане. Те се обработват от различни вериги на защитната стена и от различни настройки. Проверката на грешната верига губи следобеда и връща броячи, които изглеждат невинни.

Прочетете слушателя и маршрута

На клиента потвърдете, че адресът на тунела на сървъра се маршрутизира в тунела. На сървъра потвърдете, че има сокет на адреса, който клиентът използва, и че процесът зад него е този, който сте имали предвид.

wg show
ip route get 10.66.0.1
ss -lntup | grep -E ':80|:443'
nft list ruleset | grep -A6 'chain input'
curl -vk --max-time 5 https://10.66.0.1/

Слушател на 127.0.0.1 никога няма да отговори на заявка, адресирана до 10.66.0.1, каквото и да разрешава защитната стена. Слушател на общия адрес ще отговори, освен ако правило не го блокира. Списъкът на сокетите следователно решава половината случаи, преди да е прегледано каквото и да е правило. Портът и адресът заедно решават дали заявката може да пристигне.

Сравнете адреса, който клиентът използва, с адреса, който сървърът действително притежава на интерфейса на тунела. Остаряла конфигурация от която и да е страна създава заявка, правилно маршрутизирана към партньор, който няма такъв адрес.

Прилагайте правила за локален вход, не за препращане

Ако пакетът пристигне и сокетът съществува, оставащата граница е политиката за вход. Правило, което разрешава препращане, не разрешава локално доставяне, а правило, ограничено до един интерфейс, може да не съвпада с името на интерфейса на тунела, което очаквате.

Тествайте с един разрешен порт към желаната услуга, вместо да отваряте хоста. След това проверете собствената авторизация на приложението: списък за разрешаване, изискване за акаунт или обвързване с конкретно име на хост могат да отхвърлят заявка, която мрежата е доставила успешно.

Оставете проверките на сертификата включени. Неочакваната идентичност на сертификат е информация за това кой хост е отговорил, а не препятствие за заобикаляне. Прескачането ѝ скрива единствената следа, която идентифицира грешната услуга.

Разделяйте отказите по име, размер и идентичност

Услуга, която работи по адрес, но се проваля по име, е проблем с DNS и поправката ѝ е в конфигурацията на резолвера, изпращана към клиента, а не в защитната стена. Услуга, която отговаря на малки заявки, но засича на по-големи отговори, сочи към размера на пакета и MTU, което е съвсем друго разследване.

Грешка в HTTPS, която посочва грешен хост, обикновено означава, че заявката е стигнала до друга услуга, често защото прокси или друг слушател притежава този порт. Прочетете субекта на сертификата и го сравнете с хоста, до който сте искали да стигнете. Това сравнение не струва нищо и често приключва разследването.

Запишете коя контролна точка се е провалила: сокет, правило за вход или политика на приложението. Този един ред разграничава мрежова неизправност от решение за авторизация. Той също така пречи на следващия човек да отваря портове, които никога не са били проблемът.