Pi hotspot-kliendid ei jõua TUN VPN-i kaudu koduvõrku

Kohalikud Wi-Fi ja Ethernet kliendid ühenduvad Pi hotspotiga, võtavad selle DHCP-vahemikust aadressi ja laadivad internetilehti ilma kaebusteta. Samad kliendid aeguvad seejärel, kui nad avavad koduvõrgus failijagamise või veebiliidese, samal ajal kui Pi ise jõuab sellesse võrku tunnelis. Traadita kihis pole midagi katki. Puudu on marsruuditud leping: hotspoti prefiks tuleb kanda TUN-liidesesse ja midagi kodupoolel peab teadma, kuidas vastuseid sinna tagasi saata. Mõlemad pooled peavad olemas olema, enne kui ükski pakett saab edasi-tagasi teekonna lõpetada.

Kolm ühendust kolme erineva tööga

Linuxi Etherneti sild edastab kaadreid siht-MAC-aadressi järgi. OpenVPN TUN-režiimis kannab IP-pakette ja sellel puudub MAC-kiht täielikult, seega kohaliku silla lisamine ei kirjuta tunnelit kunagi pordiks. tuuma TUN/TAP dokumentatsioon selgitab seda eraldust: TAP-seade näeb välja nagu Etherneti liides, TUN-seade mitte. Kujundus, mis sildab kaks kohalikku porti ja seejärel marsruudib, on ruuter, ükskõik mida liideste nimed ütlevad.

See erinevus otsustab omandi. Klientide alamvõrk, nende vaikevärav ja selle vahemiku DHCP-volitus kuuluvad Pi kohalikku plaani. Kodu-DHCP-ringhäälingud ei ületa marsruuditud tunnelit ja ükski silla seade ei muuda seda; klientide suunamine kodu-DHCP-serverile on eraldi, teadlik releekujundus oma vearežiimidega.

Hoia modem ka kliendisillast väljas. PPP-ühendus ei ole Etherneti seade teise sildiga ning pppd dokumenteeritud vaikemarsruudi loogika töötab pärast IPCP läbirääkimisi ja võtab oma marsruudi tagasi, kui see link katkeb. DHCP-malli kopeerimine ja iga usb0 ümbernimetamine ppp0-ks ei tõesta midagi värava, meetrika ega elutsükli kohta.

Vali prefiksid enne, kui muudad ükskõik millist konfiguratsiooni

Kattuvad prefiksid raiskavad rohkem õhtuid kui tulemüürireeglid, sest kattuvus saadab marsruudiotsingu valesse liidesesse ka siis, kui tunnel on terve. Alusta loetlemisest, mis Pi-l juba olemas on, ja loe tulemust seejärel nelja eraldi basseerina.

ip -4 addr show scope global
ip -4 route show table main
ip -4 route get 192.168.77.10

Esimene bassein on underlay-aadress, mille operaator modemile andis; see peab jääma igast kliendile suunatud plaanist välja. Teine on tunneli alamvõrk, mille server valis, sageli tema enda privaatne /24-võrk. Kolmas on hotspoti sild ja neljas on koduprefiks, mida soovid jõuda. Selles läbimängus saab hotspot 172.28.90.0/24 sillaga 172.28.90.1 juures ning kodu teenuste LAN hoiab 192.168.77.0/24, mis väldib vaikeväärtusi 192.168.1.0/24 ja 10.0.0.0/24, millega tarbijaruuterid tulevad, ja operaatori vahemikku 100.64.0.0/10.

Teata silla aadress väravana hotspoti DHCP-vahemikus ja mitte midagi muud. Ära anna hotspot-klientidele kunagi kodu-aadressi väravana; neil pole selle segmendini lülikihi teed.

Marsruudi iga suund sellel poolel, mis seda omab

Pi vajab koduprefiksi marsruuti läbi tunneli. Serverirežiimis serverid tavaliselt lükkavad selle marsruudi, seega kinnita esmalt, et edastamine on sees ja et tuum lahendab kodu-aadressi tun0-st.

sysctl net.ipv4.ip_forward
ip route add 192.168.77.0/24 dev tun0
ip -4 route get 192.168.77.10

Kui ip route get teatab endiselt underlay-liidesest, peatu seal; miski teekonna hilisem osa ei suuda valet otsingut parandada.

Koduseadmetel pole marsruuti 172.28.90.0/24-le, seega nende vastused järgivad vaikeväravat ja surevad ruuteris. Toetatud parandusi on kaks. Kas lisa koduruuterile staatiline marsruut, mis suunab hotspoti prefiksi VPN-serveri LAN-aadressile, või kui server ise on värav, registreeri kliendi prefiks serveri enda marsruutimistabelisse. OpenVPN-i mitmekliendirežiimis kannab kliendipõhine kataloog seda seost: fail, mis on nimetatud kliendi sertifikaadi üldnime järgi ja sisaldab iroute 172.28.90.0 255.255.255.0 pluss vastavat route rida, mis paigaldab selle serveri tuuma. Oletatud tuumamarsruut serveris ei ole sama väide kui öelda serverile, milline klient prefiksi omanik on.

Ära vii koduvõrgu DHCP-teenust VPN-serverile, et see töötaks. Terve maja vaikevärava asendamine on palju suurem muudatus kui ühe privaatse tagasimarsruudi lisamine ning tõmbab DNS-i, aadressireservatsioonid ja iga seadme, mis uut rendilepingut eirab, ebaõnnestumisse.

Ava edastamine ilma tulemüüri oletamata

Edastamise sisselülitamine ei tähenda, et pakett lastakse läbi. Liiklus sillalt tunnelisse tabab endiselt filtrireegleid ja vaikimisi drop-edastuspoliitika viskab hotspot-liikluse kõrvale, samal ajal kui Pi enda liiklus töötab edasi, mis tekitab täpselt ülalse lõhestunud sümptomi.

iptables -S FORWARD
iptables -t nat -S POSTROUTING
nft list ruleset

Otsi vastuvõtureeglit br0-st tun0-le ja vastavat vastusesuunda ning postrouting-reeglit, mis võib allika ümber kirjutada. Kui ahela poliitika on drop ja ükski reegel ei sobi, lisa kitsad vastuvõtud ja testi uuesti, selle asemel et poliitika accept-iks pöörata.

Tõlkimine on poliitikavalik, mitte nõue. Allika-NAT koduvõrgu suunas paneb iga hotspot-kliendi nägema välja nagu Pi tunneli aadress, mis kaotab kliendipõhise omistamise kodulogides ja rikub teenuseid, mis ootavad algset allikat. Marsruutimine ilma NAT-ita hoiab kliendi aadressid nähtavad, kuid sõltub ülalsest tagasimarsruudist. Vali üks ja käsitle DNS-i ja IPv6-t samamoodi, sest töötav IPv4 tee katkise IPv6 tee kõrval loetakse brauseris endiselt poolkatkiseks.

Kontrolli edasi-tagasi teekonda ja siis lõhu see meelega

Testi hotspot-kliendist, mitte kunagi Pi-st, sest Pi enda liiklus möödub nii edasi- kui ka tagasiteest. Jälgi mõlemat liidest, kui üks klient üritab koduteenust jõuda.

tcpdump -ni br0 host 192.168.77.10
tcpdump -ni tun0 host 192.168.77.10
ping -c 3 192.168.77.10

Loe kahte salvestust koos. Päringud br0-l, mis ei ilmu kunagi tun0-l, tähendavad, et Pi ei edasta või marsruut osutab mujale. Päringud tun0-l ilma vastusteta tähendavad, et kodupoolel pole tagasimarsruuti või server filtreeris paketi. Vastused tun0-l, mis ei ilmu kunagi uuesti br0-l, tähendavad, et pöördfiltrireegel on puudu, kus tunnel näeb täiuslik välja ja klient ei näe ikkagi midagi.

Seejärel lõhu tee meelega. Võta modemiühendus maha ja uuesti üles ning käivita marsruudi- ja salvestuskontrollid uuesti; marsruut, mis jääb tunnelist alles, kuid kaob taasühendamisel, kuulub ühendusprofiili, mitte ühekordsesse käsku. Kinnita, et tunneli transport väljub endiselt underlay kaudu, mitte iseenda kaudu, klassikaline silmus, kui lükatud vaikemarsruut võetakse vastu ilma host-marsruudita partnerini.

Nõustu kujundusega alles siis, kui hotspot-klient suudab lahendada kodunime, avada TCP-teenuse ja hoida seansi elus üle ühe modemitaasühenduse. Kui rakendus nõuab tõesti Etherneti-tasemel avastamist koduses segmendis, vali toetatud Layer 2 kujundus, selle asemel et kirjeldada kohalikku silda sillatuna ja oodata ringhäälingu ilmumist.