A PiVPN kézfogása működik, az oldalak elakadnak: ellenőrizze a MASQUERADE-ot

A telefonja csatlakozottként mutatja az alagutat, a kliens privát címet jelent, és az első oldal továbbra is félúton elakad a betöltésben. Ez a kombináció a legtöbb embert a titkosítási beállításokhoz és a processzor hőmérsékletéhez küldi, ahol valójában semmi sincs elrontva. Az alagút feljött, tehát a tárgyalás befejeződött; ami elbukott, az a következő lépés, amikor a szerver megpróbálja átadni a kliens csomagjait az internetnek. Járja be ugyanazt az útvonalat, amelyet ezek a csomagok bejárnak, és az eltérés általában a NAT-tábla egyetlen sorában látható.

Kezdje azzal, mit ér el a kliens és mit nem

A csatlakozott kliensről töltsön be egy oldalt, amely a nyilvános interneten él, és jegyezze fel, hogy azonnal elbukik-e vagy félúton elakad. Ezután nyisson meg egy erőforrást a VPN-kiszolgáló saját privát címén, és hasonlítsa össze a két eredményt.

Az az alagútcím, amely pingre válaszol, miközben a nyilvános oldalak időtúllépésbe futnak, továbbítási vagy fordítási probléma jele, nem törött kézfogásé. A kliens saját állapotpanelje nem tudja megkülönböztetni őket, mert csak azt tudja, hogy a vezérlőcsatorna fent van. Ellenőrizze a szerveren az alagút interfészét ezzel: ip -br addr show tun0 és erősítse meg, hogy a kliensnek kiosztott cím a beállított címkészleten belülre esik. Ha a készlet és a kliens címe nem egyezik, először azt javítsa, mert az alábbi szabályok mindegyike a készletre illeszkedik.

Ezután kérdezze meg a szervert, melyik interfészt használná egy nyilvános cím eléréséhez. ip route get 203.0.113.9 az első sorában kiírja a kiválasztott eszközt és forrást. Jegyezze fel az eszköz nevét, mert a NAT-szabályban pontosan ennek az értéknek kell szerepelnie.

Olvassa el a szabályt, amely eldönti, hogy a csomagok kimennek-e

A MASQUERADE csak akkor írja át a csomagot, ha az a szabályban megnevezett interfészen keresztül távozik. A vezetékes eszközre korlátozott szabály semmit sem tesz a Wi-Fi-n kilépő forgalomért, és a csomag megtartja privát forráscímét egészen a felső routerig. Annak a routernek nincs visszaútja az alagút-készletéhez, ezért eldobja a választ, és a kliens egy kapcsolatot lát, amely megnyílik, majd meghal. A tünet azzal arányos, mennyi oldal érkezik meg, mire az első válaszra szükség van.

Listázza az élő táblát, és olvassa a kimenő interfész oszlopát, ahelyett hogy csak a MASQUERADE szót keresné. A hozzáadás formájú kimenetet könnyebb összehasonlítani, mint egy formázott listát:

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

Egy Raspberry Pi-n, amely valaha Ethernetet, most Wi-Fi-t használ, az elavult név szinte mindig maga a teljes történet. A telepítő rögzítette, milyen eszköz volt jelen a beállításkor, és a mentett szabálykészlet minden indításkor újra lejátssza. Mielőtt bármi mást módosítana, hasonlítsa össze az útvonalkeresésből kapott eszközt a szabályban szereplővel. Ha megegyeznek, az interfész nem az Ön problémája, és lépjen tovább az utolsó szakasz számlálóira. Ha eltérnek, a javítás egy szó szerkesztése a perzisztenciafájlban.

A mentett szabálykészletet javítsa, ne csak a futót

Ha csak az élő táblát szerkeszti, az a következő újraindításig tart, ami éppen elég hosszú ahhoz, hogy meggyőzze Önt a probléma megoldásáról. Az indításkor visszatérő szabályok egy olyan fájlban élnek, amelyet a tűzfal perzisztenciacsomagja tölt be újra. A Debian-alapú Pi-képeken ez a fájl általában /etc/iptables/rules.v4.

Készítsen másolatot, mielőtt hozzányúl, majd cserélje ki a MASQUERADE sor kimenő interfészét a feljegyzett eszközre, például -o wlan0 helyett -o eth0. Hagyja a forrástartományt úgy, ahogy van, hacsak a klienskészlete nem változott. Töltse újra, és erősítse meg, hogy a szabály most a helyes eszközt nevezi meg:

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

Két szomszédos beállítást könnyű elfelejteni. sysctl net.ipv4.ip_forward értéke 1 kell legyen, és a felső router nem szűrheti maga a privát forráscímeket.

Bizonyítsa, hogy a szabály működésbe lép, majd különítse el, mi még lassú

A számlálók az egyetlen őszinte bizonyíték arra, hogy egy szabály illeszkedett. Futtassa a részletes listát, indítson letöltést a kliensen, és futtassa újra. A szabály melletti csomag- és bájtoszlopoknak növekedniük kell, és a nullán maradó szabály még mindig nem illeszkedik. Ha a számlálók mozognak, de az oldalak továbbra is elbuknak, hasonlítsa össze a forrástartományt a tényleges készlettel ezzel: grep -n "^server " /etc/openvpn/server.conf. Ha mozognak és az oldalak betöltődnek, de az átvitel gyenge, a fordítás kész, és a maradék probléma máshol van.

Hasonlítson össze két átvitelt ugyanarról a kliensről, az egyiket a helyi hálózat egy hosztjára, a másikat az alagúton keresztül ugyanarra a hosztra. Mindkét esetben lassú: ez a Pi felső láncára vagy Wi-Fi-kapcsolatára utal, nem a VPN-re. Csak az alagúton keresztül lassú: ez az MTU-ra és az újraküldésekre utal, amelyeket ezzel vizsgálhat meg ip -s link show tun0 bármilyen titkosítási beállítás módosítása előtt.

A kísérlet visszavonásához állítsa vissza a másolatot, és töltse be újra, majd erősítse meg, hogy az eredeti szabály és számlálói visszatértek. Írja fel a kimenő eszközt és az újratöltési parancsot a szerver jegyzeteibe, mert a következő felső lánc módosítása újra felfedezi ugyanazt az eltérést. Az a szabály, amely rossz eszközt nevez meg, láthatatlan marad, amíg a forgalomnak szüksége nem lesz rá.