VPN-kliendid ühenduvad, kuid interneti pole: kolm puuduvat osa

Klient saab aadressi, server vastab pingidele ja ikkagi aegub iga leht. Enamik inimesi hakkab selles punktis kliendiprofiili muutma, mis on tavaliselt raisatud vaev: kui tunnel on püsti, peab server käituma ruuterina. Kolm tingimust peavad kehtima korraga, enne kui pakett väljub ja vastus tagasi tuleb, ning sümptom on sama, ükskõik milline neist puudub.

Miks töötaval tunnelil ikkagi väljapääsu pole

Kernel peab pakette liideste vahel edastama, mis on enamikus Linuxi distributsioonides vaikimisi väljas. Liiklus tuleb tõlkida aadressiks, millele välismaailm saab vastata, kui just iga ülemvoolu ruuter ei tea juba tagasiteed tunneli alavõrku. Tulemüüri edastustee peab lubama liiklust mõlemas suunas, sealhulgas vastuseid.

Igaüht neist saab eraldi parandada, ja see ongi lõks. Edastamise sisselülitamine ilma tõlkereeglita jätab paketid väljuma privaatse allikaga ja ilma tagasiteeta. Tõlkimise lisamine ilma edastusreeglita jätab kerneli paketi üks samm hiljem maha viskama.

Seega testige kolme kihti, mitte klienti, ja muutke korraga ühte, et tulemus midagi tähendaks.

Edastamine on kerneli lüliti, mille peate püsivaks tegema

Kontrollige praegust väärtust enne muutmist, seejärel seadke see ja kinnitage, et muudatus jõustus.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
sysctl net.ipv4.ip_forward

Esimene käsk näitab praegust väärtust, teine seab selle tööajal ja kolmas tõestab, et kirjutamine õnnestus. Tööaja väärtus kaob järgmisel taaskäivitusel, mistõttu töötav seanss võib pärast hooldust katkeda ilma ühegi konfiguratsioonimuudatuseta.

Tehke see püsivaks failis /etc/sysctl.d/ all ja rakendage siis see fail, selle asemel et teadasaamiseks taaskäivitada. FreeBSD-s on vaste net.inet.ip.forwarding, püsivuse jaoks gateway_enable=YES failis rc.conf. Seade, mis teatab edastamise keelatuks olevat, selgitab tervet klassi aruandeid „paketid saabuvad ja midagi ei tule tagasi”. Kontrollige seadet ka pärast igat uuendust, sest ümberehitatud kernel või vahetatud seadme kujutis võib selle kellegi teadmata lähtestada.

Valige masquerade või üks fikseeritud tõlkeaadress

Dünaamilise välisaadressi korral on masquerading kõige lihtsam õige vorm. Nimetage tunneli alavõrk allikaks ja välimine liides väljapääsuks.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -o eth0 -j MASQUERADE

Staatilise avaliku aadressi korral on allika tõlkimine täpselt sellele aadressile paremini prognoositav ja kergemini auditeeritav.

iptables -t nat -A POSTROUTING -s 10.9.0.0/24 -j SNAT --to-source 198.51.100.10

Teine vorm kannab hoolduslõksu: kõvasti kodeeritud aadress, mis hiljem muutub, hoiab tunneli töös, samal ajal kui internetiühendus vaikselt lakkab. Kasutage kas masquerade’i või värskendage reeglit alati, kui teenusepakkuja teid liigutab. Ka liides loeb, sest ruuter, mis jagab omaenda ülemvoolu tunnelit, peab tõlkima läbi selle tunneli, mitte füüsilise WAN-i.

Filtritabel on kolmas värav

Edastamine ja tõlkimine võivad mõlemad olla korrektsed, samal ajal kui pakett sureb filtritabelis. ufw on sage süüdlane: selle edastuspoliitika tuleb DROP-ina ja ülejäänud seadistus võib paista täiesti korrektne, samal ajal kui see üks säte tapab liikluse. Selle tõstmine on teadlik turvavaldik otsus, mitte märkeruut.

iptables -A FORWARD -i tun0 -o eth0 -j ACCEPT
iptables -A FORWARD -i eth0 -o tun0 -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

Esimene reegel lubab uut liiklust tunnelist väljapoole ja teine ainult vastuseid tagasi. Kitsendage mõlemad tunneli alavõrgule ja kavatsetud sihtkohale, sest tunneliliidesel üldine luba muudab VPN-i avatud väljundpunktiks kõigile, kes suudavad autentida.

Sillatud tunnel vajab teistsugust vastust. Aadress kuulub sillale, mitte füüsilisele pordile, seega liidese allutamine eemaldab aadressi, mis tal varem oli, ja host paistab kättesaamatu, kuni sild ise aadressi saab, mida dhclient br0 saab pakkuda. See tõrge näeb välja nagu VPN-i probleem ja on teise kihi probleem. Kontrollige silla enda aadressi enne tulemüüri puudutamist, sest filtrimuudatus ei paranda hosti, kellel pole enam aadressi, kust saata.

Kuhu vaadata, kui leht ei laadi kunagi

Pingige serveri tunneli aadressi, et tõestada tunneli olemasolu. Seejärel käivitage kliendist traceroute avalikule aadressile ja lugege, kuhu see peatub: serveris pakett saabub, kuid seda ei edastata ega tõlgita; serverist kaugemal on probleem ülemvoolus ja väljaspool teie käsi.

ping -c 3 10.9.0.1
traceroute -n 198.51.100.10

Esimene käsk tõestab, et tunnel viib liiklust serverini endani, ja teine näitab, kui kaugele pakett väljapoole jõuab. Tunneli aadressil lõppev jälg osutab serveri edastamisele või tõlkimisele, ühe hüppe hiljem peatuv jälg aga teenusepakkujale või ülemvoolu ruuteri tagasiteele.

Jälgige serveris välimist liidest, kui klient lehte laadib. Privaatse lähteaadressiga väljuv liiklus tähendab, et tõlkimine puudub, ja vastuse täielik puudumine tähendab, et edastustee või ülemvoolu tagasitee viskab selle maha.

Kui kaugkliendid peavad jõudma ka serveri LAN-i hostideni, pidage meeles, et LAN vajab tagasiteed tunneli alavõrku. See on marsruutimine, mitte tõlkimine, ja see on samm, mis kõige sagedamini ununeb, kui internetitee lõpuks tööle hakkab.