Tunnel püsti, internetti pole: kus edasisaatmine peatub

Klient ühendub, tunnel kannab pingid lüüsini ja midagi sellest kaugemal ei vasta. See olek on normaalne lüüsi puhul, mis oli alati mõeldud ainult juurdepääsuks kaitstud võrkudele, ja see on rike lüüsi puhul, mida reklaamitakse täistunneli väljapääsuna. Enne reeglite muutmist kinnitage, milline teenus lubati. Seejärel jälgige üht avalikku päringut läbi nelja koha, kus see võib peatuda. Üks päring ja üks paketisalvestus lahendavad rohkem kui lehekülg oletusi.

Kinnitage, kas interneti väljapääs oli üldse disain

Jaotatud tunneli profiil suunab VPN-i ainult kaitstud alamosad, nii et avalik sirvimine jätkub kohaliku lingi kaudu ega puuduta kunagi lüüsi. Täistunneli profiil paigaldab tunnelisse vaikimisi marsruudi, mis teeb lüüsist vastutaja kogu tee eest. Mõlemad on legitiimsed lahendused ja nende segamine tekitab rikkeettekande seal, kus seda pole. Lugege kliendi teatatud marsruute enne millegi muu testimist, sest marsruuditabel vastab küsimusele, mille pilet tavaliselt valesti esitab.

See, mida klient paigaldab, ei ole alati see, mida profiil kavatseb. Lükatud marsruudi võib tühistada lokaalne marsruut väiksema metrikaga, ja klient, kes hoiab LAN-marsruuti, lisades samal ajal vaikimisi marsruudi, käitub selle alamosa puhul nagu jaotatud tunnel.

Jälgige üht avalikku päringut

Valige üks sihtkoht ja jälgige seda kliendist väljapoole. Kliendis kontrollige, kas pakett valib tõesti tunneli ja millist kohalikku aadressi see allikana kasutab. Seejärel kontrollige lüüsi: kas pakett saabub ja kas see lahkub avalikust liidesest. Iga selline vastus eemaldab terve põhjuste kategooria.

ip route get 1.1.1.1
ip -4 addr show tun0
conntrack -L | grep 1.1.1.1
tcpdump -ni any host 1.1.1.1

Kui lüüs paketti kunagi ei näe, on kliendi marsruut või tunneli valik vale. Kui see saabub ega lahku, on probleem lüüsis ja kehtivad ülejäänud kolm kontrolli.

Kontrollige edasisaatmist, marsruuti ja tõlkimist

StrongSwaniga kaasas olevad edasisaatmise juhised kehtivad igat tüüpi tunneli lüüsile: tuumal peab olema lubatud pakette liideste vahel liigutada, ja kasutatav marsruut peab osutama internetti. Tulemüüri poliitika peab seejärel liikluse lubama ja allikaaadress peab olema selline, millele avalik pool saab vastata. Privaatne kliendiaadress, mis saadetakse internetti muutmata kujul, ei saa kunagi vastust.

sysctl net.ipv4.ip_forward
ip route get 1.1.1.1
nft list ruleset | grep -A6 forward
sysctl net.ipv4.conf.all.rp_filter

Allika tõlkimine on tavaline puuduv osa. Sellega kirjutab lüüs kliendi allika ümber oma avalikuks aadressiks ja jälgib voogu; ilma selleta pole vastusel kuhugi minna. Pilveplatvormid lisavad teise piiri, kus eksemplari marsruuditabel või turvagrupp võib loobuda liiklusest, mida külalise tulemüür lubab. Seda piiri on lihtne tähelepanuta jätta, sest külalissüsteem näeb seestpoolt õigesti seadistatud välja.

Vastupidise tee filtreerimine asümmeetrilises seadistuses võib samuti õigeid pakette kõrvale heita. Lugege selle reegli loendurit, selle asemel et eeldada, et see on korras, sest avaliku liidese range seade lükkab tagasi liikluse, mis saabub teist teed pidi, kui marsruuditabel ennustab.

Vastusetee ja resolver on kaks erinevat vastust

Jälgige ka vastust, mitte ainult päringut. Kui päring väljub tõlgituna ja vastus naaseb tõlgitud voogu, töötab edasisaatmine ka siis, kui rakendus ikka veel ebaõnnestub, ja järgmine uurimine kuulub rakendusele või DNS-ile.

HTTP-vea tagastav sait on tõestus, et interneti edasisaatmine töötab. Nimi, mida ei õnnestu lahendada, samal ajal kui juurdepääs aadressi kaudu töötab, on resolveri probleem, mitte NAT-i probleem.

Pärast täpset parandust testige uuesti klienti ja iga teadlikult piiratud privaatset ressurssi. Interneti juurdepääsu andmine ei tohi vaikselt laiendada juurdepääsu igale lüüsiga ühendatud võrgule.