Miks VPN-kliendi taga olev server vastab tunneli kaudu

Sissetulevad ühendused hosti, mis käitab ka VPN-klienti, nurjuvad väga kindlal viisil: käepigistus saabub, deemon vastab ja klient ei saa midagi tagasi. Miski ei blokeeri porti. Vastus lahkus tunnelist, sest tunnel omab vaikimisi marsruuti ja kernel marsruudib vastuseid sihtkoha järgi, mitte mälu järgi sellest, kust päring tuli. Deemon on korras ja port on avatud.

Vastus marsruuditakse, mitte ei mäletata

VPN-klient, mis paigaldab vaikimisi marsruudi, lisab kirje, mis ületab LAN-i lüüsi, kas meetrika või ruumi kaheks täpsemaks pooleks jagamise teel. Väljuvad paketid valivad nüüd tunneliliidese. Kernel ei küsi kunagi, kust vastatav pakett algselt saabus. See üks ärajätmine seletab kõiki järgnevaid sümptomeid.

Edasisuund marsruuditakse sihtkoha järgi, ja vastassuund samuti. Vastus on adresseeritud avalikule kliendile, kelle tunnel hea meelega edasi viib. Kaugem ots saab paketi, mille allikat ta ei oma, viskab selle ära ja algne klient ootab, kuni aeg täis saab.

Range pöördtee filtreerimine võib sissetuleva paketi ära visata enne, kui deemon seda üldse loeb. Kontrollige seda loendurit kõigepealt, sest filtri viskamine ja marsruutimisviga näevad väljastpoolt ühesugused välja.

ip route show default
sysctl net.ipv4.conf.all.rp_filter net.ipv4.conf.eth0.rp_filter
nft list ruleset | grep -A3 'hook forward'

Esimene käsk näitab, milline vaikimisi marsruut praegu võidab. Teine teatab, kas range filtreerimine kehtib globaalselt või liidese kaupa, ja kolmas näitab mis tahes edastusahela reeglit, mis võib olla seotud.

Kolm viisi tagasitee hoidmiseks

Teenuse sihtkoha tunnelist väljajätmine on kitsaim valik. LAN-i lüüsile suunatud hostimarsruut pluss deemon, mis on seotud füüsilise aadressiga, mitte iga aadressiga, hoiab selle ühe voo tunnelist väljas. Muudatus on kohalik ja kergesti tagasipööratav.

Poliitikapõhine marsruutimine on üldine vastus. Allika aadressi või tulemüüri märgi järgi võtmeks tehtud reegel valib tabeli, mille vaikimisi marsruut osutab WAN-i lüüsile, samal ajal kui hosti enda ühendused jätkavad tunneli kasutamist. Hoidke prioriteet selgesõnaline, et reeglit ei saaks hiljem varjutada.

ip rule add from 203.0.113.25/32 table 100 priority 100
ip route add default via 192.0.2.1 dev eth0 table 100
ip route get 198.51.100.7 from 203.0.113.25

Kaks esimest käsku ehitavad alternatiivse tee avalikult aadressilt lähtuvatele vastustele. Kolmas küsib kernelilt, millist teed täpselt see allikas ja sihtkoht läbiks, ja nii kinnitate, et reeglil on mingi mõju.

Allika tõlkimine on kolmas valik ja ainus, mis jääb püsima ruuteri ees, mis juba teeb teenuse ees NAT-i. Vastus peab sellesse ruuterisse tagasi jõudma, ja maskeerimine WAN-i liidesele saavutab selle, varjates kliendi teenuse logide eest. Vaikimisi marsruudi käsitsi asendamine pärast ühendamist on diagnostika, sest klient kirjutab tabeli järgmisel taasühendamisel üle.

Kui masin marsruudib ka LAN-i jaoks

Sama tõrge ilmneb ühe hüppe võrra kaugemal, kui host marsruudib enda taga olevate seadmete jaoks. Sissetulev ühendus edastatakse sisemisele seadmele, mille ainus tagasitee on tunnel, ja vastus jõuab välisesse klienti teenusepakkuja aadressilt. Sisemine seade töötab kogu aeg korralikult.

Seejärel näeb ühenduste jälgimine vastust voole, mida ta kunagi ei registreerinud, ja viskab selle ära. Sihtkoha tõlkimine toimetab sissetuleva ühenduse seadmeni ja allika tõlkimine paneb vastuse näima ruuteri enda seest tulevat.

Poliitikamarsruut, mis hoiab edastatud pordi WAN-i peal, samal ajal kui ruuteri enda liiklus kasutab tunnelit, on puhtam ekvivalent. Ilma allika tõlkimiseta on vastus adresseeritud välisele kliendile ja sisemisel seadmel pole sellele aadressile üldse marsruuti.

Kolm katset, mis eristavad põhjuseid

Tehke kolm katset: ühendus masinasse internetist, ühendus sellest välja avalikku hosti ja nimeotsing. Kui kaks esimest lahknevad, on süüdi tagasitee. Kui nimed ebaõnnestuvad mõlemas suunas, on resolver teine tõrge, mis lihtsalt jagab tunnelit.

Parandage kõigepealt marsruutimise küsimus, seejärel vaadake nimesid. Kahe segamine on viis, kuidas töötavat serverit süüdistatakse katkises resolveris.

Pange kirja, millist liidest erand nimetab, ja hoidke konfiguratsiooni versioonihalduses. Liidese vastu kirjutatud reegel, mis pärast uuendust ümber nimetatakse, läbib täna ja nurjub järgmisel taaskäivitusel.