De handshake fan PiVPN wurket, siden hingje: kontrolearje de MASQUERADE

Jo telefoan lit de tunnel as ferbûn sjen, de klant meldt in privee adres, en de earste side hinget noch healwei it laden. Dy kombinaasje stjoert de measte minsken nei fersiferingynstellingen en CPU-temperatueren, wêr't eins neat ferkeard is. De tunnel kaam omheech, dus de ûnderhanneling wie dien; wat mislearre is de stap dêrnei, as de tsjinner besiket om pakketten fan de klant oan it ynternet oer te jaan. Rin itselde paad as dy pakketten, en de mismatch is meastentiids sichtber yn ien rigel fan de NAT-tabel.

Begjin by wat de klant wol en net berikke kin

Fan de ferbûne klant, laad in side dy't op it iepenbiere ynternet wennet en notearje oft dy fuortdaliks mislearret of healwei hinget. Iepenje dêrnei in boarne op it eigen privee adres fan de VPN-tsjinner en fergelykje de beide resultaten.

In tunneladres dat ping beantwurdet wylst iepenbiere siden de tiid ferrane, is it teken fan in trochstjoer- of oersettingsprobleem, net fan in brutsen handshake. It statuspaniel fan de klant sels kin dy net ûnderskiede, om't it allinnich wit dat it kontrôlekanaal omheech is. Kontrolearje op de tsjinner de tunnelinterface mei ip -br addr show tun0 en befêstigje dat it adres dat de klant krigen hat binnen de pool falt dy't jo ynsteld hawwe. As de pool en it klantadres net oerienkomme, reparearje dat earst, om't elke regel hjirûnder op de pool oerienkomt.

Freegje de tsjinner dêrnei hokker interface er brûke soe om in iepenbier adres te berikken. ip route get 203.0.113.9 printet it keazen apparaat en de boarne op syn earste rigel. Skriuw dy apparaatnamme op, om't dat de wearde is dy't de NAT-regel befetsje moat.

Lês de regel dy't beslút oft pakketten fuortgeane

MASQUERADE skriuwt in pakket allinnich oer as it pakket fuortgiet troch de interface dy't yn de regel neamd wurdt. In regel dy't beheind is ta in betelle apparaat docht neat foar ferkear dat oer Wi-Fi fuortgiet, en it pakket hâldt syn privee boarneadres oant de boppeste router. Dy router hat gjin weromrûte nei jo tunnelpool, dus hy smyt it antwurd fuort, en de klant sjocht in ferbining dy't iepent en dan stjert. It symptoom skaalet mei hoefolle fan de side oankomt foardat it earste antwurd nedich is.

List de libbene tabel op en lês de kolom fan de útgonginterface ynstee fan allinnich op it wurd MASQUERADE te sykjen. De útfier fan de tafoegfoarm is makliker te fergelykjen as in opmakke list:

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

Op in Raspberry Pi dy’t eartiids Ethernet brûkte en no Wi-Fi brûkt, is de ferâldere namme hast altyd it hiele ferhaal. De ynstallearder registrearre hokker apparaat by it ynstellen oanwêzich wie, en de bewarre regelset spilet dat by elke opstart wer ôf. Fergelykje it apparaat út ’e rûtesyktocht mei dat yn ’e regel foardat jo eat oars feroarje. As se oerienkomme, is de interface net jo probleem en moatte jo nei de tellers yn ’e lêste seksje gean. As se ferskille, is de reparaasje in bewurking fan ien wurd yn it persistinsjebestân.

Reparearje de bewarre regelset, net allinnich de rinnende

Allinnich de libbene tabel bewurkje hâldt oant de folgjende werstart, en dat is krekt lang genôch om jo te oertsjûgjen dat it probleem oplost is. De regels dy’t by it opstarten weromkomme, wenje yn in bestân dat in firewall-persistinsjepakket wer lade. Op Debian-basearre Pi-ôfbylden is dat bestân meastentiids /etc/iptables/rules.v4.

Nim in kopy foardat jo it oanreitsje, ferfange dan de útgonginterface op de MASQUERADE-rigel troch it apparaat dat jo opskreaun hawwe, bygelyks -o wlan0 yn plak fan -o eth0. Lit it boarneberik sa’t it is, útsein as jo klantpool feroare is. Laad wer en befêstigje dat de regel no it goede apparaat neamt:

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

Twa neistlizzende ynstellingen wurde maklik fergetten. sysctl net.ipv4.ip_forward moat 1 rapportearje, en de boppeste router mei gjin privee boarneadressen sels filterje.

Bewis dat de regel ôfgiet, en isolearje dan wat noch stadich is

Tellers binne it iennichste earlike bewiis dat in regel oerienkaam. Rin de wiidweidige list, start in download op de klant en rin dy wer. De pakket- en byte-kolommen njonken jo regel moatte stige, en in regel dy’t op nul bliuwt, komt noch altyd net oerien. As de tellers bewege mar de siden mislearje noch, fergelykje it boarneberik mei de echte pool mei grep -n "^server " /etc/openvpn/server.conf. As se bewege en de siden lade mar de trochstream is min, is de oersetting dien en is it oerbleaune probleem earne oars.

Fergelykje twa oerdrachten fan deselde klant, ien nei in host op it lokale netwurk en ien troch de tunnel nei deselde host. Stadich yn beide gefallen wiist nei de boppeste keppeling fan de Pi of de Wi-Fi-ferbining, net nei de VPN. Stadich allinnich troch de tunnel wiist nei MTU en werhellings, dy’t jo besjen kinne mei ip -s link show tun0 foardat jo hokker krypto-ynstelling dan ek feroarje.

Om it eksperimint werom te draaien, restaurearje de kopy en laad dy wer, befêstigje dan dat de oarspronklike regel en syn tellers werom binne. Skriuw it útgongapparaat en it werlaadkommando yn ’e tsjinnernotysjes, om’t de folgjende feroaring fan ’e boppeste keppeling deselde mismatch wer ûntdekt. In regel dy’t it ferkearde apparaat neamt, bliuwt ûnsichtber oant ferkear him nedich hat.