Gumagana ang handshake ng PiVPN, nag-hang ang mga pahina: suriin ang MASQUERADE

Ipinapakita ng telepono ang tunnel bilang konektado, nag-uulat ang client ng pribadong address, at nakabitin pa rin ang unang pahina sa kalagitnaan ng pag-load. Ang kombinasyong iyon ay nagpapadala sa karamihan sa mga setting ng cipher at temperatura ng CPU, kung saan wala talagang mali. Bumangon ang tunnel, kaya tapos na ang negosasyon; ang nabigo ay ang susunod na hakbang, kapag sinusubukan ng server na ihatid ang mga packet ng client sa internet. Sundan ang parehong landas na tinatahak ng mga packet na iyon, at ang mismatch ay karaniwang makikita sa isang linya ng NAT table.

Magsimula sa kung ano ang naaabot at hindi naaabot ng client

Mula sa konektadong client, i-load ang isang pahina na nasa pampublikong internet at tandaan kung agad itong nabigo o natigil sa kalagitnaan. Pagkatapos buksan ang isang resource sa sariling pribadong address ng VPN server at ihambing ang dalawang resulta.

Ang address ng tunnel na tumutugon sa ping habang nag-expire ang mga pampublikong site ay senyales ng problema sa forwarding o pagsasalin, hindi ng sirang handshake. Hindi kayang paghiwalayin ng status panel ng client ang dalawa, dahil alam lang nito na nakabangon ang control channel. Suriin sa server ang interface ng tunnel gamit ang ip -br addr show tun0 at tiyakin na ang address na ibinigay sa client ay nasa loob ng pool na na-configure mo. Kung hindi tugma ang pool at ang address ng client, ayusin muna iyon, dahil bawat rule sa ibaba ay tumutugma sa pool.

Susunod, tanungin ang server kung aling interface ang gagamitin nito para maabot ang pampublikong address. ip route get 203.0.113.9 ipinapakita ang napiling device at source sa unang linya nito. Isulat ang pangalan ng device, dahil iyon ang value na dapat taglayin ng NAT rule.

Basahin ang rule na nagpapasya kung aalis ang mga packet

Ang MASQUERADE ay nagsusulat muli ng packet lamang kapag lumalabas ang packet sa interface na binanggit sa rule. Ang rule na nakatali sa wired device ay walang ginagawa para sa traffic na lumalabas sa Wi-Fi, at pinapanatili ng packet ang pribadong source address nito hanggang sa upstream router. Walang ruta pabalik sa iyong tunnel pool ang router na iyon, kaya itinatapon nito ang sagot, at nakikita ng client ang koneksyon na bumubukas at pagkatapos ay namamatay. Lumalaki ang sintomas sa dami ng pahina na dumarating bago kailanganin ang unang sagot.

Ilista ang live table at basahin ang column ng out-interface sa halip na hanapin lamang ang salitang MASQUERADE. Mas madaling ihambing ang output sa add form kaysa sa naka-format na listahan:

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

Sa isang Raspberry Pi na dating gumamit ng Ethernet at ngayon ay Wi-Fi, ang lumang pangalan ang halos palaging buong kuwento. Itinala ng installer kung aling device ang naroon noong setup, at inuulit ito ng naka-save na ruleset sa bawat boot. Ihambing ang device mula sa route lookup sa nasa rule bago magbago ng iba pa. Kung tugma sila, hindi ang interface ang problema mo at dapat kang pumunta sa mga counter sa huling bahagi. Kung magkaiba, ang pagwawasto ay isang salitang edit sa persistence file.

Ayusin ang naka-save na ruleset, hindi lamang ang tumatakbo

Ang pag-edit lamang ng live table ay tumatagal hanggang sa susunod na reboot, na sapat na para kumbinsihin kang naayos na ang problema. Ang mga rule na bumabalik sa boot ay nakatira sa isang file na muling nilo-load ng firewall persistence package. Sa mga Pi image na nakabatay sa Debian, ang file na iyon ay karaniwang /etc/iptables/rules.v4.

Kumuha ng kopya bago ito hawakan, pagkatapos palitan ang out-interface sa MASQUERADE line ng device na itinala mo, halimbawa -o wlan0 sa halip na -o eth0. Iwanan ang source range kung ano ito, maliban kung nagbago ang client pool mo. I-load muli at tiyakin na tinutukoy na ng rule ang tamang device:

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

Dalawang magkatabing setting ang madaling kalimutan. sysctl net.ipv4.ip_forward dapat mag-ulat ng 1, at hindi dapat i-filter ng upstream router ang mga pribadong source address nang mag-isa.

Patunayan na pumapasok ang rule, pagkatapos ihiwalay kung ano pa ang mabagal

Ang mga counter ang tanging tapat na patunay na tumugma ang isang rule. Patakbuhin ang detalyadong listahan, magsimula ng download sa client at patakbuhin itong muli. Dapat tumaas ang mga column ng packet at byte sa tabi ng rule mo, at ang rule na nananatiling zero ay hindi pa rin tumutugma. Kung gumagalaw ang mga counter pero nabibigo pa rin ang mga pahina, ihambing ang source range sa aktwal na pool gamit ang grep -n "^server " /etc/openvpn/server.conf. Kung gumagalaw at naglo-load ang mga pahina pero mahina ang throughput, tapos na ang pagsasalin at ang natitirang problema ay nasa ibang lugar.

Ihambing ang dalawang transfer mula sa parehong client, isa sa host sa lokal na network at isa sa tunnel patungo sa parehong host. Mabagal sa parehong kaso ay tumutukoy sa uplink ng Pi o sa Wi-Fi connection, hindi sa VPN. Mabagal lamang sa tunnel ay tumutukoy sa MTU at retransmissions, na maaari mong suriin gamit ang ip -s link show tun0 bago baguhin ang anumang crypto setting.

Para bawiin ang eksperimento, ibalik ang kopya at i-load muli ito, pagkatapos tiyakin na bumalik ang orihinal na rule at ang mga counter nito. Isulat ang egress device at ang reload command sa mga tala ng server, dahil matutuklasan muli ng susunod na pagbabago ng uplink ang parehong mismatch. Ang rule na tumutukoy sa maling device ay nananatiling hindi nakikita hanggang kailanganin ito ng traffic.