Yhdistetty OpenVPN:ään, mutta mikään ei lataudu: kierros asiakkaasta ulospäin

Asiakasikkuna sanoo Connected, tunnelin osoite on siinä, ja selain pyörii yhä. Yhdistelmä on normaali, koska onnistunut kättely todistaa vain, että tunneli rakennettiin; se ei kerro, välittääkö palvelin pakettisi eteenpäin, kirjoittaako niiden lähteen uudelleen vai vastaako DNS-kyselyihisi. Useimpien tekemä virhe on avata ensin palvelimen kokoonpano. Etene sen sijaan asiakkaasta ulospäin, koska jokainen alla oleva vaihe kertoo, kannattaako seuraavaa edes tarkistaa.

Aloita asiakkaasta ja etene ulospäin

Tee kolme testiä tässä järjestyksessä ja kirjoita ylös, mihin ensimmäinen kaatuu. Pingaa palvelimen tunneliosoitetta, mikä todistaa, että tunneli itse kuljettaa liikennettä. Pingaa julkista osoitetta numerolla, mikä todistaa välityksen ja käännöksen ilman nimien selvitystä. Yritä sitten selvittää isäntänimi, mikä on ainoa testi, joka käyttää DNS:ää. Jokainen tulos poistaa kokonaisen kerroksen epäilyistä.

Älä hyppää kolmanteen testiin, koska selain tuntuu nopeammalta. Epäonnistunut sivun lataus kattaa kaikki kolme kerrosta kerralla, ja juuri siitä aloittamalla ihmiset päätyvät rakentamaan toimivan tunnelin uudelleen. Epäonnistuva sivu ei kerro, mikä kolmesta hajosi.

Kaksi kaappausta näyttää, mihin paketit pysähtyvät

Kun asiakkaasta pingaa julkiseen osoitteeseen, ota yksi kaappaus tunneliliitännältä ja yksi ylävirran linkiltä, jonka pitäisi päästä internetiin. Aja molemmat samaan aikaan, jotta aikaleimat osuvat kohdalleen.

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

Jos pyynnöt näkyvät tunnelilla eivätkä koskaan ylävirran linkillä, palvelin pudotti ne tunnelin ja johdon välissä, ja syy on välitys tai välityksen palomuurikäytäntö, ei NAT. Jos ne näkyvät molemmilla, palvelin teki osuutensa ja vastaus puuttuu kauempaa, mikä viittaa käännökseen, ylävirran suodattimeen tai palveluntarjoajan rajoitukseen.

Hae ylävirran linkin nimi reititystaulusta, älä opetusohjeesta. Pilvikuvat ja uudelleennimetyt sovittimet harvoin vastaavat oppaan esimerkkiliitäntää, ja väärällä laitteella otettu kaappaus näyttää täsmälleen palvelimelta, joka ei välitä:

ip -4 route get 9.9.9.9

Kenttä dev tuossa tulosteessa on nimi, jota NAT-sääntö tarvitsee myöhemmin, joten pidä se.

Välitys on ytimen kytkin ja palomuurin käytäntö

Ytimen on ylipäätään suostuttava välittämään. Lue nykyinen arvo ja tee asetuksesta sitten pysyvä sen sijaan, että kirjoittaisit sen vain käynnissä olevaan ytimeen:

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

Välitys on vain puolet. UFW:ää käyttävällä isännällä välityskäytäntö asetetaan tiedostossa /etc/default/ufw, ja sen on oltava ACCEPT ennen kuin uudelleenlataus vaikuttaa. Oletusarvoinen pudotus välityspolulla jättää kättelyn täysin terveeksi mutta heittää hiljaa pois jokaisen paketin, joka yrittää lähteä tunnelin kautta, ja juuri se on oire, jolla aloitit.

Isännät, jotka hallitsevat nftablesia suoraan, kohtaavat saman kysymyksen eri syntaksissa. Seuraa välitysketjun laskureita asiakastestin aikana, koska ketju, jolta kysytään, ja ketju, joka pudottaa, näyttävät kokoonpanotiedostossa samalta.

Nimeä todellinen lähtöliitäntä NAT-säännössä

Lähteen käännös kuuluu liitännälle, joka todella poistuu isännältä, sillä allaskokonaisuudella, jonka palvelin jakaa. Säännön molempien puoliskojen on kuvattava todellisuutta, eikä kumpikaan ole valinnainen.

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

Klassinen epäonnistuminen on oppaasta kopioitu sääntö, joka sanoo -o eth0 koneella, jonka sovitin on nimeltään jotain muuta. Sääntö asentuu ilman varoitusta, ei vastaa mitään, ja asiakkaalla ei ole yhä internettiä. Allas on saman virheen toinen puolisko: jos palvelin jakaa 10.44.0.0/24 ja sääntö kattaa 10.8.0.0/24, mikään ei koskaan vastaa.

Seuraa laskureita sen sijaan, että luottaisit säännön tekstiin. Listaus kertoo paketit säännöittäin, ja sääntö, joka ei koskaan vastaa, jää nollaan, niin oikealta kuin se näyttääkin. Anna sille minuutti todellista asiakasliikennettä ennen kuin luet siitä luvusta mitään:

iptables -t nat -L POSTROUTING -v -n

Nolla pakettia todellisen asiakastestin jälkeen tarkoittaa, että osuma on väärä, ei että tunneli on rikki. Kun se osuu, tallenna sääntöjoukko, jotta se kestää uudelleenkäynnistyksen; korjaus, joka elää vain komentotulkkisi historiassa, katoaa ensimmäisellä uudelleenkäynnistyksellä.

Jos palvelin on myös pilven NAT-instanssi, myös alustalla on sanansa. Osoitteita kääntävä instanssi tarvitsee yleensä lähteen ja kohteen tarkistuksen pois päältä siellä, missä palveluntarjoaja tarjoaa sen asetuksen, ja VPN-portin itsensä on oltava saavutettavissa ulkopuolelta.

DNS on toinen epäonnistuminen ensimmäisen takana

Osoitteella pingaaminen toimii, kun nimet epäonnistuvat, on selvittimen ongelma, ja sillä on oma syynsä. Asiakas, joka pitää paikallisen selvittimensä, lähettää ne kyselyt täyteen tunneliin ja odottaa vastausta, joka ei koskaan tule, koska paikallinen selvitin on nyt reitin väärällä puolella.

Työnnä selvitin palvelimelta, jotta asiakas tietää, mistä kysyä. Kaksi merkintää antavat asiakkaalle varavaihtoehdon, jos ensimmäinen ei ole saavutettavissa, ja molempien pitäisi olla selvittimiä, jotka tunneli todella sallii.

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

Windows-asiakkaat voivat silti palata paikalliseen selvittimeen, ja juuri sen block-outside-dns on tarkoitettu estämään, sen hinnalla, että menetetään nimet, jotka vain paikallinen verkko voi selvittää. systemd-resolvedia käyttävät Linux-asiakkaat jättävät usein työnnetyn selvittimen huomiotta, ellei skripti asenna sitä, joten tarkista resolvectl status tunnelilaitteelle ennen kuin päättelet, että työntö jätettiin huomiotta.

Viimeistele kierros niin kuin käyttäjä sen kokee. Lataa asiakkaasta todellinen sivu, vahvista osoite, josta se lähtee, käynnistä palvelin uudelleen, yhdistä uudelleen ja toista kolme testiä. Vain se toinen kierros todistaa, että tallennetut säännöt, palomuurikäytäntö ja työnnetty selvitin kaikki selvisivät yhdessä.