WireGuardi kätlemine töötab, teenus mitte

Kätlemine lõpeb, klient näitab värsket ülekande loendurit ja ometi ebaõnnestub päring samas serveris asuvale teenusele. See kombinatsioon ajab inimesi segadusse, sest tunnel töötab tõestatavalt. Tõestamata on kohalik kohaletoimetamine: pakett jõudis hostini ja host peab selle endiselt õiges socketis vastu võtma ning andma edasi protsessile, millel on vastamise luba. Käige need kolm kontrollpunkti järjekorras läbi.

Peatuge esimesel, mis ei kehti, ja ärge lisage teiste jaoks reegleid.

Kätlemine tõestab ainult tunnelit

WireGuardi kätlemine loob võtmed partnerite vahel ja lubab liiklust vahemikele, mille iga partner loetles. See ei ütle midagi selle kohta, millised protsessid serveris kuulavad, ega selle kohta, kas hosti tulemüür võtab vastu pakette, mis on adresseeritud mõnele tema enda aadressile.

Just viimane eristus jääb kõige sagedamini märkamata: liiklus hosti enda juurde on kohalik sisend, samas kui liiklus, mis läbib hosti ja suundub mujale, on edasisaatmine. Neid käsitlevad erinevad tulemüüri ahelad ja erinevad seaded. Vale ahela kontrollimine kulutab pool päeva ja annab loendurid, mis näivad süütud.

Lugege kuulajat ja marsruuti

Kliendis veenduge, et serveri tunneli aadress marsruutub tunnelisse. Serveris veenduge, et kliendi kasutataval aadressil on socket olemas ja et selle taga olev protsess on see, mida kavatsesite.

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/

Kuulaja aadressil 127.0.0.1 ei vasta kunagi päringule, mis on adresseeritud aadressile 10.66.0.1, ükskõik mida tulemüür lubab. Kuulaja metamärgi aadressil vastab, kui reegel ei blokeeri teda. Socketite loend lahendab seega poole juhtudest enne, kui ühtegi reeglit vaadatakse. Port ja aadress koos otsustavad, kas päring saab kohale jõuda.

Võrrelge aadressi, mida klient kasutab, aadressiga, mis serveril tunneli liidesel tegelikult on. Vananenud konfiguratsioon kummalgi poolel annab päringu, mis marsruutub õigesti partnerile, kellel seda aadressi pole.

Rakendage reegleid kohaliku sisendi jaoks, mitte edasisaatmise jaoks

Kui pakett saabub ja socket on olemas, on allesjäänud piir sisendpoliitika. Edasisaatmist lubav reegel ei luba kohalikku kohaletoimetamist ja ühele liidesele piiratud reegel ei pruugi sobida oodatava tunneli liidese nimega.

Testige ühe lubatud pordiga sihtteenusele, selle asemel et host avada. Seejärel kontrollige rakenduse enda autoriseerimist: lubatud loend, konto nõue või seondumine kindla hostinimega võivad tagasi lükata päringu, mille võrk edukalt kohale toimetas.

Jätke sertifikaadi kontrollid alles. Ootamatu sertifikaadi identiteet on teave selle kohta, milline host vastas, mitte takistus, millest tuleks mööda minna. Sellest läbi klikkides peidate ainsa vihje, mis tuvastab vale teenuse.

Eristage nime, suuruse ja identiteedi tõrkeid

Teenus, mis töötab aadressi järgi, kuid ebaõnnestub nime järgi, on DNS-probleem ja parandus kuulub kliendile saadetavasse resolveri konfiguratsiooni, mitte tulemüüri. Teenus, mis vastab väikestele päringutele, kuid jääb suuremate vastuste juures tõkke taha, viitab paketi suurusele ja MTU-le, mis on hoopis teine uurimine.

Vale hosti nimetav HTTPS-viga tähendab tavaliselt, et päring jõudis teise teenuseni, sageli seetõttu, et pordi omanik on puhverserver või teine kuulaja. Lugege sertifikaadi subjekt ja võrrelge seda hostiga, kuhu tahtsite jõuda. See võrdlus ei maksa midagi ja lõpetab uurimise sageli.

Kirjutage üles, milline kontrollpunkt ebaõnnestus: socket, sisendreegel või rakenduse poliitika. See üks rida eristab võrgutõrget autoriseerimisotsusest. Samuti takistab see järgmisel inimesel avada porte, mis ei olnud kunagi probleem.