OpenVPN-iga ühendatud, aga miski ei laadi: ringkäik kliendi poolt väljapoole

Kliendi aken ütleb Connected, tunneli aadress on olemas ja brauser keerleb endiselt. See kombinatsioon on normaalne, sest edukas kätlus tõestab ainult seda, et tunnel on ehitatud; see ei ütle midagi selle kohta, kas server suunab sinu paketid edasi, kirjutab nende allika ümber või vastab sinu DNS-päringutele. Enamik inimeste viga on avada kõigepealt serveri konfiguratsioon. Tööta hoopis kliendist väljapoole, sest iga allolev samm ütleb, kas järgmist tasub üldse kontrollida.

Alusta kliendist ja liigu väljapoole

Tee kolm testi selles järjekorras ja kirjuta üles, kus esimene ebaõnnestub. Pingi serveri tunneli aadressi, mis tõestab, et tunnel ise kannab liiklust. Pingi avalikku aadressi numbri järgi, mis tõestab edasisuunamist ja tõlget ilma nimelahendust kaasamata. Seejärel proovi lahendada hostinime, mis on ainus test, mis rakendab DNS-i. Iga tulemus eemaldab kahtlusest terve kihi.

Ära hüppa kolmanda testi juurde sellepärast, et brauser tundub kiirem. Ebaõnnestunud lehe laadimine katab kõik kolm kihti korraga ja just sealt alustades hakatakse töötavat tunnelit uuesti ehitama. Ebaõnnestuv leht ei ütle sulle, milline kolmest katki läks.

Kaks püüdmist näitavad, kus paketid peatuvad

Kui kliendist jookseb ping avalikku aadressi, tee üks püüdmine tunneli liidesel ja teine üleslingil, mis peaks internetti jõudma. Käivita mõlemad korraga, et ajatemplid ühtiksid.

sudo tcpdump -ni tun0 -c 20 icmp
sudo tcpdump -ni enp1s0 -c 20 icmp

Kui päringud ilmuvad tunnelis ja mitte kunagi üleslingil, viskas server need tunneli ja kaabli vahel ära ning põhjus on edasisuunamine või edasisuunamise tulemüüripoliitika, mitte NAT. Kui need ilmuvad mõlemas, tegi server oma osa ja vastus on puudu kaugemal, mis viitab tõlkele, ülalvoolu filtrile või teenusepakkuja piirangule.

Võta üleslingi nimi ruutimistabelist, mitte õpetusest. Pilvepildid ja ümbernimetatud adapterid sobivad juhendi näidisliidesega harva ning vale seadme peal tehtud püüdmine näeb välja täpselt nagu server, mis ei suuna edasi:

ip -4 route get 9.9.9.9

Väli dev selles väljundis on nimi, mida NAT-reegel hiljem vajab, seega hoia see alles.

Edasisuunamine on kerneli lüliti ja tulemüüri poliitika

Kernel peab üldse edasisuunamisega nõustuma. Loe praegune väärtus ja tee seade siis püsivaks, selle asemel et kirjutada see ainult jooksvasse kerneli:

sysctl net.ipv4.ip_forward
printf 'net.ipv4.ip_forward=1\n' > /etc/sysctl.d/70-vpn-forward.conf
sysctl --system

Edasisuunamine on ainult pool. UFW-d kasutaval hostil seatakse edasisuunamise poliitika failis /etc/default/ufw ja see peab olema ACCEPT enne, kui uuesti laadimine mõjub. Vaikimisi langetamine edasisuunamise teel jätab kätluse täiesti terveks, kuid viskab vaikselt ära iga paketi, mis üritab tunnelist väljuda, ja see on täpselt see sümptom, millega alustasid.

Hostid, kes haldavad nftablesi otse, seisavad sama küsimuse ees teises süntaksis. Jälgi edasisuunamise ahela loendureid kliendi testi ajal, sest ahel, mille poole pöördutakse, ja ahel, mis langetab, näevad konfiguratsioonifailis ühesugused välja.

Nimeta NAT-reeglis tegelik väljundliides

Allika tõlge kuulub liidesele, mis hostist tegelikult väljub, koos basseiniga, mille server välja jagab. Selle reegli mõlemad pooled peavad kirjeldama tegelikkust ja kumbki ei ole valikuline.

iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o enp1s0 -j MASQUERADE

Klassikaline ebaõnnestumine on juhendist kopeeritud reegel, mis ütleb -o eth0 masinal, mille adapter kannab teist nime. Reegel paigaldatakse ilma hoiatuseta, ei sobi millegagi ja kliendil pole endiselt internetti. Bassein on sama vea teine pool: kui server jagab 10.44.0.0/24 ja reegel katab 10.8.0.0/24, ei sobi miski kunagi.

Jälgi loendureid, selle asemel et usaldada reegli teksti. Loend näitab pakette reegli kohta ja reegel, mis kunagi ei sobi, jääb nulli, ükskõik kui õige see välja näeb. Anna sellele minut tegelikku kliendiliiklust enne, kui loed sellesse numbrisse midagi sisse:

iptables -t nat -L POSTROUTING -v -n

Null pakkide arv pärast tegelikku klienditesti tähendab, et vaste on vale, mitte et tunnel on katki. Kui see sobib, salvesta reeglistik, et see restartiks püsiks; parandus, mis elab ainult sinu shelli ajaloos, kaob esimesel restardil.

Kui server on ka pilve-NAT-i eksemplar, on platvormil samuti sõna. Eksemplar, mis aadresse tõlgib, vajab tavaliselt välja lülitatud allika- ja sihtkoha kontrolli seal, kus teenusepakkuja seda seadet pakub, ja VPN-port ise peab olema väljastpoolt kättesaadav.

DNS on teine ebaõnnestumine esimese taga

Aadressi järgi pingimine töötab, aga nimed ebaõnnestuvad — see on resolveri probleem, ja sellel on oma põhjus. Klient, kes hoiab oma kohalikku resolverit, saadab need päringud täis-tunnelisse ja ootab vastust, mis ei tule kunagi, sest kohalik resolver on nüüd marsruudi valel poolel.

Lükka serverist resolver välja, et klient teaks, kust küsida. Kaks kirjet annavad kliendile varuvariandi, kui esimene pole kättesaadav, ja mõlemad peaksid olema resolverid, mida tunnel tegelikult lubab.

push "dhcp-option DNS 9.9.9.9"
push "dhcp-option DNS 149.112.112.112"

Windowsi kliendid võivad siis ikkagi kohalikule resolverile tagasi langeda, ja just seda on block-outside-dns mõeldud takistama, hinnaga, et kaotatakse nimed, mida ainult kohalik võrk suudab lahendada. Linuxi kliendid, kes kasutavad systemd-resolvedi, eiravad sageli väljalükatud resolverit, kui skript seda ei paigalda, seega kontrolli tunnelseadme jaoks resolvectl status enne, kui järeldad, et lükkamine jäeti tähelepanuta.

Lõpeta ringkäik nii, nagu kasutaja seda kogeb. Laadi kliendist tegelik leht, kinnita aadress, millelt see väljub, taaskäivita server, ühenda uuesti ja korda kolme testi. Ainult see teine ring tõestab, et salvestatud reeglid, tulemüüri poliitika ja väljalükatud resolver püsisid kõik koos.