PiVPN-i kätlus töötab, lehed takerduvad: kontrollige MASQUERADE-i

Teie telefon näitab tunnelit ühendatuna, klient teatab privaatsest aadressist ja esimene leht jääb ikkagi poole laadimise peal rippuma. See kombinatsioon saadab enamiku inimesi šifri seadetesse ja protsessori temperatuuri juurde, kus tegelikult pole midagi valesti. Tunnel tõusis, seega läbirääkimine lõppes; ebaõnnestus järgmine samm, kui server üritab kliendi pakette internetti üle anda. Käige sama rada, mida need paketid käivad, ja lahknevus on tavaliselt nähtav NAT-tabeli ühes reas.

Alustage sellest, mida klient suudab ja ei suuda kätte saada

Ühendatud kliendist laadige leht, mis asub avalikus internetis, ja pange tähele, kas see ebaõnnestub kohe või takerdub poole peal. Seejärel avage ressurss VPN-serveri enda privaatsel aadressil ja võrrelge kahte tulemust.

Tunneli aadress, mis vastab ping-idele, samal ajal kui avalikud saidid aeguvad, on edastus- või tõlkeprobleemi märk, mitte katkise kätluse oma. Kliendi enda olekupaneel ei suuda neid eristada, sest see teab ainult, et juhtkanal on üleval. Kontrollige serveris tunneli liidest käsuga ip -br addr show tun0 ja kinnitage, et kliendile määratud aadress jääb teie seadistatud aadressibasseini sisse. Kui bassein ja kliendi aadress ei klapi, parandage see esimesena, sest iga allolev reegel vastab basseinile.

Järgmisena küsige serverilt, millist liidest see avaliku aadressi jaoks kasutaks. ip route get 203.0.113.9 prindib valitud seadme ja allika oma esimesel real. Kirjutage see seadme nimi üles, sest just see väärtus peab NAT-reeglis olema.

Lugege reeglit, mis otsustab, kas paketid väljuvad

MASQUERADE kirjutab paketi ümber ainult siis, kui pakett lahkub reeglis nimetatud liidese kaudu. Juhtmega seadmele piiratud reegel ei tee midagi Wi-Fi kaudu väljuvale liiklusele ja pakett hoiab oma privaatset lähteaadressi kuni ülemise ruuterini. Sellel ruuteril pole tagasiteed teie tunneli basseini, seega viskab see vastuse ära ja klient näeb ühendust, mis avaneb ja siis sureb. Sümptom kasvab sellega, kui palju lehte jõuab kohale enne, kui on vaja esimest vastust.

Loetlege elav tabel ja lugege väljundliidese veergu, selle asemel et lihtsalt otsida sõna MASQUERADE. Lisamisvormi väljundit on lihtsam võrrelda kui vormindatud loendit:

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

Raspberry Pi-l, mis kunagi kasutas Etherneti ja nüüd Wi-Fi-t, on vananenud nimi peaaegu alati kogu lugu. Paigaldaja registreeris, milline seade oli seadistamise ajal olemas, ja salvestatud reeglistik kordab seda igal käivitusel. Enne millegi muu muutmist võrrelge marsruudiotsingust saadud seadet reeglis olevaga. Kui need klapivad, pole liides teie probleem ja peaksite liikuma viimase jaotise loendurite juurde. Kui need erinevad, on parandus ühe sõna muudatus püsivusfailis.

Parandage salvestatud reeglistikku, mitte ainult töötavat

Ainult elava tabeli muutmine püsib järgmise taaskäivituseni, mis on täpselt küllalt pikk, et veenda teid, et probleem on lahendatud. Reeglid, mis käivitusel tagasi tulevad, elavad failis, mille tulemüüri püsivuspakett uuesti laadib. Debianil põhinevatel Pi-kujutistel on see fail tavaliselt /etc/iptables/rules.v4.

Tehke koopia enne, kui seda puudutate, seejärel asendage MASQUERADE-real väljundliides seadmega, mille üles kirjutasite, näiteks -o wlan0 asemel -o eth0. Jätke lähtevahemik samaks, kui teie kliendibassein pole muutunud. Laadige uuesti ja kinnitage, et reegel nimetab nüüd õiget seadet:

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

Kaht kõrvutist seadet on lihtne unustada. sysctl net.ipv4.ip_forward peab teatama 1 ja ülemine ruuter ei tohi privaatseid lähteaadresse ise filtreerida.

Tõestage, et reegel rakendub, ja seejärel eraldage, mis on veel aeglane

Loendurid on ainus aus tõestus, et reegel tabas. Käivitage üksikasjalik loend, alustage kliendis allalaadimist ja käivitage see uuesti. Teie reegli kõrval olevad pakettide ja baitide veerud peaksid kasvama ning nullile jääv reegel ei taba endiselt. Kui loendurid liiguvad, aga lehed ikka ebaõnnestuvad, võrrelge lähtevahemikku tegeliku basseiniga käsuga grep -n "^server " /etc/openvpn/server.conf. Kui need liiguvad ja lehed laadivad, aga läbilaskevõime on halb, on tõlkimine tehtud ja ülejäänud probleem on mujal.

Võrrelge kahte ülekannet samast kliendist, üks kohaliku võrgu hostile ja teine läbi tunneli samale hostile. Aeglane mõlemal juhul osutab Pi ühendusliinile või Wi-Fi-lingile, mitte VPN-ile. Aeglane ainult läbi tunneli osutab MTU-le ja kordussaadetele, mida saate uurida käsuga ip -s link show tun0 enne mis tahes krüpto-seade muutmist.

Eksperimendi tagasipööramiseks taastage koopia ja laadige see uuesti, seejärel kinnitage, et algne reegel ja selle loendurid on tagasi. Kirjutage väljundseade ja uuestilaadimise käsk serveri märkmetesse, sest järgmine ühendusliini muudatus avastab sama lahknevuse uuesti. Vale seadet nimetav reegel jääb nähtamatuks seni, kuni liiklus seda vajab.