PiVPN-handskud werk, bladsye staak: ondersoek die MASQUERADE

Jou foon wys die tonnel as verbind, die kliënt rapporteer ’n private adres, en die eerste bladsy hang steeds halfpad deur die laai. Daardie kombinasie stuur die meeste mense na syferinstellings en CPU-temperature, waar niks eintlik verkeerd is nie. Die tonnel het opgekom, dus het die onderhandeling klaar gemaak; wat misluk het, is die stap daarna, wanneer die bediener probeer om kliëntpakkette na die internet te oorhandig. Volg dieselfde pad wat daardie pakkette neem, en die wanverhouding is gewoonlik in een reël van die NAT-tabel sigbaar.

Begin by wat die kliënt kan bereik en wat nie

Laai vanaf die gekoppelde kliënt ’n bladsy wat op die publieke internet woon, en let op of dit dadelik misluk of halfpad staak. Maak dan ’n hulpbron op die VPN-bediener se eie private adres oop en vergelyk die twee uitkomste.

’n Tonneladres wat pings beantwoord terwyl publieke werwe uitty, is die kenmerk van ’n deurstuur- of vertaalprobleem, nie van ’n gebreekte handskud nie. Die kliënt se eie statuspaneel kan dit nie onderskei nie, want dit weet net dat die beheerkanaal op is. Kyk op die bediener na die tonnelkoppelvlak met ip -br addr show tun0 en bevestig dat die kliënt se toegewysde adres binne die poel val wat jy opgestel het. As die poel en die kliëntadres van mekaar verskil, maak dit eerste reg, want elke reël hieronder pas by die poel.

Vra die bediener volgende watter koppelvlak hy sou gebruik om ’n publieke adres te bereik. ip route get 203.0.113.9 druk die gekose toestel en bron op sy eerste reël. Skryf daardie toestelnaam neer, want dit is die waarde wat die NAT-reël moet bevat.

Lees die reël wat besluit of pakkette uitgaan

MASQUERADE herskryf ’n pakket net wanneer die pakket deur die koppelvlak vertrek wat in die reël genoem word. ’n Reël wat op ’n bedrade toestel gemik is, doen niks vir verkeer wat oor Wi-Fi uitgaan nie, en die pakket behou sy private bronadres tot by die opstroomroeteerder. Daardie roeteerder het geen roete terug na jou tonnelpoel nie, so dit laat die antwoord val, en die kliënt sien ’n verbinding wat oopgaan en dan doodgaan. Die simptoom skaal met hoeveel van die bladsy aankom voordat die eerste antwoord nodig is.

Lys die lewende tabel en lees die uitkoppelvlak-kolom eerder as om net vir die woord MASQUERADE te soek. Die byvoegvorm-uitvoer is makliker om te vergelyk as ’n geformateerde lys:

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

Op ’n Raspberry Pi wat eens Ethernet gebruik het en nou Wi-Fi gebruik, is die verouderde naam byna altyd die hele storie. Die installeerder het aangeteken watter toestel tydens die opstelling teenwoordig was, en die gestoorde reëlversameling speel dit by elke herbegin terug. Vergelyk die toestel uit die roeteopsoek met dié in die reël voordat jy iets anders verander. As hulle ooreenstem, is die koppelvlak nie jou probleem nie en moet jy na die tellers in die laaste afdeling gaan. As hulle verskil, is die oplossing ’n wysiging van een woord in die volhardingslêer.

Maak die gestoorde reëlversameling reg, nie net die lopende een nie

Om net die lewende tabel te wysig, hou tot die volgende herbegin, wat presies lank genoeg is om jou te oortuig dat die probleem opgelos is. Die reëls wat by die herbegin terugkom, woon in ’n lêer wat ’n vuurmuur-volhardingspakket herlaai. Op Debian-gebaseerde Pi-beelde is daardie lêer gewoonlik /etc/iptables/rules.v4.

Neem ’n afskrif voordat jy dit aanraak, en vervang dan die uitkoppelvlak op die MASQUERADE-reël met die toestel wat jy aangeteken het, byvoorbeeld -o wlan0 in plaas van -o eth0. Hou die bronreeks soos dit is, tensy jou kliëntpoel verander het. Herlaai en bevestig dat die reël nou die regte toestel noem:

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

Twee aangrensende instellings is maklik om te vergeet. sysctl net.ipv4.ip_forward moet 1 rapporteer, en die opstroomroeteerder mag nie private bronadresse op sy eie filter nie.

Bewys dat die reël vuur, en isoleer dan wat nog stadig is

Tellers is die enigste eerlike bewys dat ’n reël gepas het. Voer die verbose lys uit, begin ’n aflaai op die kliënt en voer dit weer uit. Die pakket- en grepe-kolomme langs jou reël behoort te klim, en ’n reël wat op nul bly, pas steeds nie. As die tellers beweeg maar bladsye steeds misluk, vergelyk die bronreeks met die werklike poel met grep -n "^server " /etc/openvpn/server.conf. As hulle beweeg en bladsye laai maar die deurset is swak, is die vertaling klaar en die oorblywende probleem is elders.

Vergelyk twee oordragte vanaf dieselfde kliënt, een na ’n gasheer op die plaaslike netwerk en een deur die tonnel na dieselfde gasheer. Stadig in beide gevalle wys na die Pi se opstroom- of Wi-Fi-skakel, nie na die VPN nie. Stadig net deur die tonnel wys na MTU en herversendings, wat jy kan inspekteer met ip -s link show tun0 voordat jy enige kripto-instelling verander.

Om die eksperiment ongedaan te maak, herstel die afskrif en herlaai dit weer, en bevestig dan dat die oorspronklike reël en sy tellers terug is. Skryf die uitgangstoestel en die herlaaiopdrag in die bedienernotas, want die volgende opstroomverandering herontdek dieselfde wanverhouding. ’n Reël wat die verkeerde toestel noem, bly onsigbaar totdat verkeer dit nodig het.