PiVPN-kättely toimii, sivut jumittuvat: tarkista MASQUERADE

Puhelimesi näyttää tunnelin yhdistettynä, asiakas ilmoittaa yksityisen osoitteen, ja ensimmäinen sivu jää silti jumiin latauksen puoliväliin. Tämä yhdistelmä lähettää useimmat ihmiset salausasetuksiin ja prosessorin lämpötiloihin, joissa mikään ei itse asiassa ole vialla. Tunneli nousi, joten neuvottelu päättyi; epäonnistui seuraava vaihe, jossa palvelin yrittää luovuttaa asiakkaan paketit internetiin. Kulje samaa reittiä, jota ne paketit kulkevat, ja epäsuhta näkyy yleensä NAT-taulun yhdellä rivillä.

Aloita siitä, mihin asiakas pääsee ja mihin ei

Lataa yhdistetystä asiakkaasta sivu, joka sijaitsee julkisessa internetissä, ja huomioi, epäonnistuuko se heti vai jumittuuko se puolivälissä. Avaa sitten resurssi VPN-palvelimen omasta yksityisestä osoitteesta ja vertaa kahta tulosta.

Tunnelin osoite, joka vastaa pingiin samalla kun julkiset sivustot aikakatkeavat, on merkki edelleenlähetyksen tai käännöksen ongelmasta, ei rikkoutuneesta kättelystä. Asiakkaan oma tilapaneeli ei pysty erottamaan niitä, koska se tietää vain, että ohjauskanava on ylhäällä. Tarkista palvelimelta tunnelin liitäntä komennolla ip -br addr show tun0 ja vahvista, että asiakkaalle annettu osoite osuu määrittämääsi osoitealtaaseen. Jos allas ja asiakkaan osoite eivät täsmää, korjaa se ensin, koska jokainen alla oleva sääntö täsmää altaaseen.

Kysy seuraavaksi palvelimelta, mitä liitäntää se käyttäisi julkiseen osoitteeseen pääsemiseen. ip route get 203.0.113.9 tulostaa valitun laitteen ja lähteen ensimmäisellä rivillään. Kirjoita laitteen nimi muistiin, koska juuri tämä arvo NAT-säännössä täytyy olla.

Lue sääntö, joka päättää, lähtevätkö paketit

MASQUERADE kirjoittaa paketin uudelleen vain silloin, kun paketti poistuu säännössä nimetyn liitännän kautta. Johdolliseen laitteeseen rajattu sääntö ei tee mitään Wi-Fi:n kautta lähtevälle liikenteelle, ja paketti säilyttää yksityisen lähdeosoitteensa ylempään reitittimeen asti. Sillä reitittimellä ei ole paluureittiä tunnelialtaaseesi, joten se pudottaa vastauksen, ja asiakas näkee yhteyden, joka avautuu ja sitten kuolee. Oire kasvaa sen mukaan, kuinka paljon sivusta saapuu ennen kuin ensimmäinen vastaus tarvitaan.

Listaa elävä taulu ja lue lähtöliitännän sarake sen sijaan, että etsit vain sanaa MASQUERADE. Lisäysmuodon tulostetta on helpompi verrata kuin muotoiltua luetteloa:

ip -br addr show tun0
ip route get 203.0.113.9
sudo iptables -t nat -S POSTROUTING

Raspberry Pi:ssä, joka käytti ennen Ethernetiä ja nyt Wi-Fi:tä, vanhentunut nimi on lähes aina koko tarina. Asentaja tallensi, mikä laite oli paikalla asennuksen aikana, ja tallennettu sääntösarja toistaa sen joka käynnistyksellä. Vertaa reittihaun laitetta säännössä olevaan ennen kuin muutat mitään muuta. Jos ne täsmäävät, liitäntä ei ole ongelmasi, ja sinun pitäisi siirtyä viimeisen osan laskureihin. Jos ne eroavat, korjaus on yhden sanan muutos pysyvyystiedostossa.

Korjaa tallennettu sääntösarja, älä vain käynnissä olevaa

Vain elävän taulun muokkaaminen kestää seuraavaan uudelleenkäynnistykseen, mikä on juuri tarpeeksi kauan vakuuttamaan sinut siitä, että ongelma on ratkaistu. Säännöt, jotka palaavat käynnistyksessä, asuvat tiedostossa, jonka palomuurin pysyvyyspaketti lataa uudelleen. Debian-pohjaisissa Pi-kuvissa tuo tiedosto on yleensä /etc/iptables/rules.v4.

Ota kopio ennen kuin kosket siihen, korvaa sitten MASQUERADE-rivin lähtöliitäntä muistiin kirjoittamallasi laitteella, esimerkiksi -o wlan0 tilalla -o eth0. Jätä lähdeverkkoalue ennalleen, ellet asiakasallastasi ole muutettu. Lataa uudelleen ja vahvista, että sääntö nimeää nyt oikean laitteen:

sudo cp /etc/iptables/rules.v4 /root/rules.v4.bak
sudo iptables-restore < /etc/iptables/rules.v4
sudo iptables -t nat -L POSTROUTING -v -n

Kaksi vierekkäistä asetusta unohtuu helposti. sysctl net.ipv4.ip_forward täytyy raportoida 1, eikä ylempi reititin saa suodattaa yksityisiä lähdeosoitteita itse.

Todista, että sääntö laukeaa, ja eristä sitten mikä on vielä hidasta

Laskurit ovat ainoa rehellinen todiste siitä, että sääntö on osunut. Aja yksityiskohtainen luettelo, aloita lataus asiakkaalla ja aja se uudelleen. Säännösi vieressä olevien paketti- ja tavusarakkeiden pitäisi kasvaa, ja nollassa pysyvä sääntö ei vieläkään osu. Jos laskurit liikkuvat mutta sivut yhä epäonnistuvat, vertaa lähdeverkkoaluetta todelliseen altaaseen komennolla grep -n "^server " /etc/openvpn/server.conf. Jos ne liikkuvat ja sivut latautuvat mutta läpäisykyky on huono, käännös on valmis ja jäljellä oleva ongelma on muualla.

Vertaa kahta siirtoa samasta asiakkaasta, toista paikallisverkon isäntään ja toista tunnelin kautta samaan isäntään. Hitaus molemmissa tapauksissa viittaa Pi:n ylälinkkiin tai Wi-Fi-yhteyteen, ei VPN:ään. Hitaus vain tunnelin kautta viittaa MTU:hun ja uudelleenlähetyksiin, joita voit tutkia komennolla ip -s link show tun0 ennen kuin muutat mitään salausasetusta.

Kumoa koe palauttamalla kopio ja lataamalla se uudelleen, vahvista sitten, että alkuperäinen sääntö ja sen laskurit ovat palanneet. Kirjoita lähtölaite ja uudelleenlatauskomento palvelimen muistiinpanoihin, koska seuraava ylälinkin muutos löytää saman epäsuhdan uudelleen. Sääntö, joka nimeää väärän laitteen, pysyy näkymättömänä, kunnes liikenne tarvitsee sitä.