hostapd at OpenVPN sa isang Pi: kanino ang default na ruta?

Kumakabit ang mga telepono sa access point, tumatanggap ng address, at pagkatapos ay wala silang naaabot sa sandaling umangat ang tunnel. Karaniwang malusog ang hostapd sa ganoong kalagayan, at gayundin ang OpenVPN; ang nasisira ay ang default na ruta, na maaaring hindi kailanman umiral sa bridge o pinalitan ng tunnel nang walang iniwang landas patungo sa mismong VPN server. Ibinabalik ng gabay na ito ang rutang iyon sa tamang lugar at pinatutunayan ang resulta mula sa isang kliyente at hindi mula sa Pi. Bawat hakbang ay maibabalik, at wala rito ang nagbabago sa configuration ng tunnel hanggang alam mo kung anong trapiko ang gusto mo sa loob nito.

Iimbentaryo ang mga interface bago mag-edit ng kahit ano

Inilalagay ng karaniwang layout ang wireless radio at ang wired port sa loob ng br0, pinapagana ang hostapd laban sa bridge at namamahagi ng lease mula sa dnsmasq, habang ang isang OpenVPN client ay gumagawa ng tun0. Pagkatapos ay tila isa lang ang tatlong magkakahiwalay na pangangailangan: kailangan ng mga kliyente ng access point ang Pi bilang kanilang gateway, kailangan ng Pi ng ruta patungo sa internet upang maabot ang server nito, at kailangan ng bridge ng gateway address na magagamit ng mga kliyenteng iyon.

Basahin ang kasalukuyang kalagayan bago ito baguhin, dahil hinihiwalay ng apat na utos na ito ang problema sa interface mula sa problema sa routing.

ip -br addr
ip route show
ip link show master br0
bridge link show

Kung may address ang br0 pero walang default na ruta, naaabot ng mga kliyente ang Pi at wala nang iba pa. Kung tumuturo ang default na ruta sa tun0 habang nakababa ang tunnel, wala talagang gumaganang landas ang Pi, at ang sintomas ng kliyente ay mukhang eksaktong pareho. Magkapareho ang hitsura ng dalawang kaso mula sa telepono, kaya dapat basahin nang direkta ang talahanayan ng ruta.

Bigyan ang bridge ng default na rutang pag-aari nito

Madalas na iniiwan ng Raspberry Pi OS ang bridge na walang default na ruta kapag nabuo ang bridge matapos isulat ang file ng interface. Nabibilang ang bloke sa /etc/dhcpcd.conf, at dapat nitong pangalanan ang upstream router at hindi ang Pi.

interface br0
static ip_address=192.168.50.2/24
static routers=192.168.50.1
static domain_name_servers=192.168.50.1

Sa halimbawang iyon, ang 192.168.50.1 ay ang umiiral na router at ang 192.168.50.2 ay ang bridge address ng Pi sa parehong subnet, kaya palitan ito ng sarili mong plano sa halip na kopyahin ang mga numero. Hindi rin dapat humiling ng router ang mga miyembro ng bridge, kung hindi ay maiiwan ang Pi na may magkakalabang default kung saan ang panalo ay nakasalalay sa metric at timing at hindi sa layunin.

Pagkatapos ng systemctl restart dhcpcd, dapat ilista ng ip route show default ang br0 nang isang beses at walang duplicate mula sa wired port. Tiyakin ang paghahanap at hindi ang talahanayan, dahil maaaring umupo ang lumang entry sa tabi ng nananalo: dapat pangalanan ng ip -4 route get 203.0.113.10 ang br0. Ang address na iyon ay mula sa documentation range na TEST-NET-3, kaya hindi ito maaaring bumangga sa isang tunay na server habang binabasa mo ito.

Pigilan ang tunnel na agawin ang landas patungo sa sarili nitong server

Kinukuha ng OpenVPN client na tumatanggap ng redirect-gateway ang default na ruta at itinuturo ito sa loob ng tunnel. Tama iyon kapag dapat gamitin ng bawat kliyente ng access point ang VPN, at mali kapag ilang destinasyon lang ang dapat. Sa alinmang paraan, ang sariling koneksyon ng Pi sa server ay hindi dapat dumaan sa loob ng tunnel na ginagawa pa nito. Nagdaragdag ang OpenVPN ng host route patungo sa malayo sa pamamagitan ng orihinal na gateway kapag iniredirekta nito ang default, at iyon mismo ang pag-uugaling nagpapanatili ng transportasyong buhay; kung wala ang rutang iyon, babagsak ang tunnel sa sandaling magtatag ito.

Ang mabilis na paghahambing ng landas ng transportasyong iyon bago at pagkatapos kumonekta ay sulit sa sampung segundong iyon. Dapat pangalanan ng ip -4 route get 203.0.113.10 ang underlay device sa parehong estado, ang metric lang ang nagbabago. Kung pangalanan nito ang tun0 pagkatapos umangat ang tunnel, hindi kailanman na-install ang host route at mabibigo ang susunod na muling pagkonekta.

Kapag piniling prefix lang ang dapat tumawid sa tunnel, gamitin ang route-nopull at idagdag nang manu-mano ang mga rutang gusto mo, o magpadala ng mas makitid na set mula sa server. Pinapanatili ng bridge ang default na ruta sa design na iyon, at ang DNS ang susunod na desisyon: may saysay lang ang pagpapasa ng dnsmasq sa isang home resolver para sa mga pangalang aktwal na nakatira doon.

Magpasya sa usapin ng forwarding at NAT

Ang buong tunnel ay nangangailangan ng forwarding na naka-enable sa Pi at ng gateway sa kabilang panig na handang mag-ruta ng subnet ng access point. Suriin ang forwarding bago ang lahat, dahil ginagawang walang kaugnayan ng zero ang bawat pagbabago ng ruta.

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 192.168.50.0/24 -o tun0 -j MASQUERADE

Ang tuntunin ng NAT ay ang shortcut na gumagana kapag hindi tatanggapin ng server ang prefix ng access point, kapalit ng paglitaw ng bawat kliyente bilang tunnel address ng Pi sa mga log sa kabilang panig. Ang pag-ruta ng prefix nang walang NAT ay nagpapanatiling nakikita ang mga address at nakasalalay sa return route para sa 192.168.50.0/24 sa panig ng bahay.

Isulat ang pinili sa tabi ng mga tuntunin ng firewall, dahil ang NAT rule na hindi nakikita sa disenyo ay nagiging hindi maipaliwanag pagkalipas ng anim na buwan. Panatilihin ang IPv6 sa parehong desisyon; ang gumaganang landas ng IPv4 sa tabi ng sirang landas ng IPv6 ay binabasa pa rin bilang kalahating sira sa browser.

I-verify mula sa isang kliyente, pagkatapos ay i-rollback nang malinis

Subukan sa ganitong pagkakasunod-sunod mula sa telepono o laptop sa access point: isang lease mula sa dnsmasq, isang ping sa bridge address, pagkatapos ay isang destinasyon sa kabilang panig ng tunnel. Hinihiwalay ng bawat hakbang ang isang layer sa halip na gumawa ng isang walang silbing kabiguan.

ip -4 route get 203.0.113.10
ping -c 3 -I br0 203.0.113.10

Pagkatapos, tiyakin na may sariling labasan pa ang Pi: dapat pangalanan ng ip route get 203.0.113.10 ang underlay device, at dapat tumugon ang ping -c 3 -I br0 203.0.113.10 kung pinapayagan ng server ang ICMP. Kung pumasa ang unang dalawang hakbang ng kliyente at nabigo ang pangatlo, nasa forwarding o NAT ang depekto. Kung nabigo ang pangalawang hakbang, hindi pa kumpleto ang bridge o DHCP.

Ang rollback ay isang pag-edit ng file at dalawang utos: alisin ang bloke, i-restart ang dhcpcd, at palitan nang tahasan ang default na ruta ng ip route replace default via 192.168.50.1 dev br0. Gawin ito bago magsara ang maintenance window at hindi pagkatapos, dahil ang Pi na nawalan ng default na ruta ay hindi maabot mula sa network na gagamitin mo upang ayusin ito.