Ракувањето на 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 грешка што го именува погрешниот домаќин обично значи дека барањето стигнало до друга услуга, често затоа што прокси или друг слушач ја поседува таа порта. Прочитајте го субјектот на сертификатот и споредете го со домаќинот до кој сакавте да стигнете. Таа споредба не чини ништо и често го завршува истражувањето.

Запишете која контролна точка не успеа: сокет, влезно правило или политика на апликацијата. Таа една линија разликува мрежен дефект од одлука за авторизација. Таа исто така спречува следниот човек да отвора порти што никогаш не биле проблем.