Miks teie LAN ei jõua VPN-kliendi teenuseni

Teie tunnel töötab, teenus kuulab, ja kontori LAN ei saa ikkagi midagi tagasi. Keegi ei rikkunud VPN-i. LAN-i poolelt ei ole sülearvuti tunneli aadress olemas enne, kui miski ütleb LAN-ile, kuidas sinna jõuda, ja vastus peab tagasi tulema sama teed, mida mööda päring välja läks. Ma olen näinud inimesi täiesti korras tunnelit kolm korda uuesti üles ehitamas, enne kui keegi tagasiteed vaatas.

Tunnel ei olegi see, mis katki läks

Mõlemad otsad istuvad privaatsetes vahemikes, mis on tavaline juhtum ja mitte vale seadistus. Aadress nagu 10.8.0.6 on tunneli sees tõeline ja mujal olematu, nii et LAN-il pole põhjust sinna midagi saata. Enne marsruutimise puutumist veenduge, et teenus on üldse tunneli sees kättesaadav: kliendil näitab ss -ltn, kas kuulaja seob end 127.0.0.1, LAN-i liidese või tunneli aadressiga. Ainult loopbacki seotud deemon ei vasta kellelegi peale iseenda, ja seda ei muuda ükski marsruut, DNAT ega pordiedastus.

Puhverserver pordil 80 või 443 on teine tööriist teise nähtavusega. See liigutab päringuid, mitte pakette, seega on see toore andmebaasiühenduse jaoks vale kiht, ja just selle järele haaramine viib selle probleemi kolm tööriista sügavale, enne kui keegi midagi mõõdab.

Marsruudi kuju: öelge LAN-ile, kus bassein asub

Staatiline marsruut LAN-i lüüs on kõige puhtam vastus, kui LAN ja tunneli bassein ei kattu. Suunake bassein masinale, mis tunneli lõpetab:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

See parandab ainult ühe suuna, ja seetõttu näevad selle muudatuse poolikud versioonid edusammuna. Tunneli poolel on vaja vastavat poolt, muidu lahkub vastus kliendist tema enda vaikimisi marsruudi kaudu ja sureb teel:

push "route 192.168.1.0 255.255.255.0"

Alamvõrgu jaoks, mis asub ühe kliendi taga, mitte serveri taga, on serveril vaja nii süsteemset marsruuti kui ka iroute kirjet selle kliendi failis client-config-dir all. Ilma iroute-ta teab OpenVPN, et prefiks on olemas, ja ei tea aimugi, milline klient seda omab: paketid saabuvad ja deemonil pole nendega midagi siduda.

Siin on müüt, mida tasub nimetada. Marsruut teeb aadressi kättesaadavaks; see ei tee vastaspoolt vastama valmis. Saidi-saidi partnerid lisavad selle peale veel ühe kihi, sest kauglüüs aktsepteerib ainult allikaid, mis on tema poliitikas loetletud prefiksite sees, ja kodubasseinist saabuv sülearvuti ei ole nende sees.

NAT-i kuju: DNAT sisse ja SNAT-rida, mille kõik vahele jätavad

Kui te ei saa LAN-i lüüsi puutuda või tahate avaldada täpselt ühe pordi, töötab tõlkimine VPN-hostis ilma ühegi marsruudita LAN-is. Avaldage port, edastage see ja tõlkige allikas tunnelisse suunduval teel:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Kolmas rida on see, mis kaob. Jätke see vahele ja klient näeb algset LAN-i aadressi allikana, vastab oma vaikimisi marsruudi kaudu, ja see vastus läheb tunnelisse, mitte tagasi LAN-i poole. Kas ühendus jääb püsima, sõltub siis marsruutimisest, mida te kunagi ei planeerinud. SNAT-iga näeb klient serveri tunneli aadressi, nii et vastus järgib tunnelit tagasi ainsa hostini, mis saab tõlkimise tagasi pöörata.

Tarbijate püsivara kasutab oma ahelate nimesid ega genereeri seda tõlget teie eest. Tomato puhul maandub sissetulev reegel WANPREROUTING-s ja seejärel filtreerimisahelas nagu wanin, ning täielikuna näiv reeglistik vajab ikkagi käsitsi POSTROUTING-rida. See ei ole püsivara viga; see on reeglistik, mis on kirjutatud ainult sissetuleva liikluse jaoks.

Miks õigena näiv reegel paketi ikkagi maha viskab

Enamik neist tõrgetest ei ole reeglis, mille otsa te vaatate. Kontrollige nelja asja selles järjekorras ja peatuge esimesel, mis ei kehti:

• Ahelate järjekord. iptables -I lisab üles ja -A lisab lõppu, seega otsustab varem lubav või blokeeriv reegel esimesena.
• Vale ahel. Ruuterile endale adresseeritud liiklus läbib INPUT-i ja edastatud liiklus ei puutu seda kunagi. Ühe teenuse avaldamine võib nõuda reegleid mõlemas.
• Suuna lipud. -i tun0 sobib klientidelt saabuva liiklusega ja -o tun0 nende poole mineva liiklusega. Vale lipuga REJECT blokeerib midagi, mida te ei kavatsenud.
• Allika piirang. Edastus, mis aktsepteerib üht kliendi aadressi, töötab sellest kliendist ja viskab iga teise allika sõnatult maha.

Nullpaketilugejaga reegel ei ole üldse teel, ja lugejate lugemine on kiireim viis eraldada vale ahela probleemi vale reegli probleemist.

Kohalik edastus, kui LAN-is ei saa midagi muuta

Kohalik SSH-edastus möödub kogu küsimusest. See ei vaja marsruuti LAN-is, kliendi tulemüüri koostööd ega kuskil avaldatud porti:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Teenus ilmub siis selle masina localhost:3000-l, mis tunnelit hoiab, ja mitte kuskil mujal. See on piir: üks tööjaam, üks port, ja edastus sureb koos seansiga, kui miski seda uuesti ei käivita. Testandmebaasi kontrollivale administraatorile on see õige tööriist. Kaamerale või skannerile, kuhu teised inimesed peavad pääsema, see ei ole, sest iga kasutaja vajaks oma edastust.

Kontrollige mõlemat suunda enne veel ühe reegli lisamist

Tõlkimine jätab jälgi ja nende lugemine on parem kui oletamine. VPN-hostis näitab conntrack -L, kas tõlkimine üldse toimus, iptables -t nat -L -n -v näitab, kas lugejad liikusid, ja tcpdump -ni any port 3000 näitab, milline allikaaadress tegelikult saabus. Kliendis kinnitab ss -ltn, et kuulaja on aadressil, kuhu tunnel pääseb.

Seejärel valige kuju, mille te alles jätate. Üks avaldatud port, marsruut kogu basseini jaoks ja edastus ühele administraatorale on kolm erinevat kohustust, ja nende segamine on see, kuidas töötav seadistus muutub selliseks, mida keegi ei oska kuus kuud hiljem seletada. Kirjutage üles, milline aadress kust on kättesaadav, ja järgmine inimene, kes seda silub, alustab vastusest, mitte tunnelist.