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

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