Rokovanje WireGuard deluje, storitev ne

Rokovanje se zaključi, odjemalec pokaže svež števec prenosa, pa zahteva do storitve na istem strežniku vseeno ne uspe. Ta kombinacija ljudi zmede, ker tunel očitno deluje. Kar ni dokazano, je lokalna dostava: paket je prispel do gostitelja, gostitelj pa ga mora še sprejeti na pravi vtičnici in ga predati procesu z dovoljenjem za odgovor. Pojdite skozi te tri kontrolne točke po vrsti.

Ustavite se pri prvi, ki ne velja, in za ostale ne dodajajte pravil.

Rokovanje dokazuje samo tunel

Rokovanje WireGuard vzpostavi ključe med partnerji in odobri promet za obsege, ki jih je vsak partner navedel. Ne pove ničesar o tem, kateri procesi poslušajo na strežniku, niti o tem, ali požarni zid gostitelja sprejema pakete, naslovljene na enega od njegovih lastnih naslovov.

Prav ta zadnja razlika se najpogosteje spregleda: promet do gostitelja samega je lokalni vhod, medtem ko je promet, ki gre skozi gostitelja drugam, posredovanje. Obravnavajo ju različne verige požarnega zidu in različne nastavitve. Preverjanje napačne verige stane popoldne in vrne števce, ki izgledajo nedolžno.

Preberite poslušalca in pot

Na odjemalcu potrdite, da se naslov tunela strežnika usmerja v tunel. Na strežniku potrdite, da vtičnica obstaja na naslovu, ki ga uporablja odjemalec, in da je proces za njo tisti, ki ste ga nameravali.

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/

Poslušalec na 127.0.0.1 nikoli ne bo odgovoril na zahtevo, naslovljeno na 10.66.0.1, ne glede na to, kaj požarni zid dovoli. Poslušalec na splošnem naslovu bo, razen če ga pravilo blokira. Seznam vtičnic torej razreši polovico primerov, preden se pregleda katero koli pravilo. Vrata in naslov skupaj odločita, ali lahko zahteva prispe.

Primerjajte naslov, ki ga uporablja odjemalec, z naslovom, ki ga strežnik dejansko ima na vmesniku tunela. Zastarela konfiguracija na kateri koli strani ustvari zahtevo, pravilno usmerjeno k partnerju, ki tega naslova nima.

Uporabite pravila za lokalni vhod, ne za posredovanje

Če paket prispe in vtičnica obstaja, je preostala meja vhodna politika. Pravilo, ki dovoljuje posredovanje, ne dovoljuje lokalne dostave, in pravilo, omejeno na en vmesnik, morda ne ustreza pričakovanemu imenu vmesnika tunela.

Preizkusite z enimi dovoljenimi vrati do ciljne storitve, namesto da odprete gostitelja. Nato preverite lastno avtorizacijo aplikacije: seznam dovoljenih, zahteva po računu ali vezava na določeno ime gostitelja lahko zavrne zahtevo, ki jo je omrežje uspešno dostavilo.

Pustite preverjanja potrdil na mestu. Nepričakovana identiteta potrdila je informacija o tem, kateri gostitelj je odgovoril, ne ovira, ki bi jo bilo treba obiti. Klik mimo nje skrije edino sled, ki prepozna napačno storitev.

Ločite napake imena, velikosti in identitete

Storitev, ki deluje po naslovu, a ne uspe po imenu, je težava DNS, popravek pa spada v konfiguracijo razreševalnika, ki se pošilja odjemalcu, ne v požarni zid. Storitev, ki odgovarja na majhne zahteve, a se ustavi pri večjih odgovorih, kaže na velikost paketa in MTU, kar je povsem druga preiskava.

Napaka HTTPS z napačnim gostiteljem običajno pomeni, da je zahteva dosegla drugo storitev, pogosto zato, ker ta vrata zaseda posrednik ali drug poslušalec. Preberite subjekt potrdila in ga primerjajte z gostiteljem, do katerega ste hoteli priti. Ta primerjava nič ne stane in pogosto konča preiskavo.

Zapišite, katera kontrolna točka je spodletela: vtičnica, vhodno pravilo ali politika aplikacije. Ta ena vrstica loči omrežno okvaro od odločitve o avtorizaciji. Prav tako prepreči, da bi naslednja oseba odprla vrata, ki nikoli niso bila problem.