Pi hotspot klientai nepasiekia namų LAN per TUN VPN

Vietiniai Wi-Fi ir Ethernet klientai prisijungia prie Pi hotspot'o, gauna adresą iš jo DHCP diapazono ir be nusiskundimų įkelia interneto puslapius. Tada tie patys klientai sulaukia laiko limito, kai atidaro failų bendrinimą arba žiniatinklio sąsają namų LAN tinkle, o pats Pi pasiekia tą LAN per tunelį. Belaidžiame sluoksnyje nieko nesugedę. Trūksta maršrutuotos sutarties: hotspot prefiksas turi būti perkeltas į TUN sąsają, ir kažkas namų pusėje turi žinoti, kaip atsakymus siųsti atgal. Abi pusės turi egzistuoti, kol vienas paketas gali užbaigti kelionę pirmyn ir atgal.

Trys prisijungimai su trimis skirtingais darbais

Linux Ethernet tiltas persiunčia kadrus pagal paskirties MAC adresą. OpenVPN TUN režimu perneša IP paketus ir visiškai neturi MAC sluoksnio, todėl vietinio tilto pridėjimas niekada neregistruoja tunelio kaip prievado. branduolio TUN/TAP dokumentacija paaiškina šį atskyrimą: TAP įrenginys atrodo kaip Ethernet sąsaja, TUN įrenginys – ne. Dizainas, kuris sujungia du vietinius prievadus ir tada maršrutizuoja, yra maršrutizatorius, kad ir ką sakytų sąsajų pavadinimai.

Šis skirtumas nusprendžia nuosavybę. Klientų potinklis, jų numatytoji tinklo vartai ir to diapazono DHCP teisė priklauso Pi vietiniam planui. Namų DHCP transliacijos neperžengia maršrutuoto tunelio, ir jokia tilto nuostata to nekeičia; nukreipti klientus į namų DHCP serverį yra atskiras, sąmoningas relay dizainas su savo gedimo režimais.

Laikykite modemą ir už klientų tilto ribų. PPP prisijungimas nėra Ethernet įrenginys su kita etikete, o dokumentuota pppd numatytojo maršruto logika veikia po IPCP derybų ir atšaukia savo maršrutą, kai ta jungtis nutrūksta. DHCP šablono kopijavimas ir kiekvieno usb0 pervadinimas į ppp0 nieko neįrodo apie vartus, metriką ar gyvavimo ciklą.

Pasirinkite prefiksus prieš redaguodami bet kokią konfigūraciją

Persidengiantys prefiksai praranda daugiau vakarų nei užkardos taisyklės, nes persidengimas siunčia maršruto paiešką į netinkamą sąsają net tada, kai tunelis sveikas. Pradėkite nuo to, kas jau yra Pi, ir tada skaitykite rezultatą kaip keturis atskirus baseinus.

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

Pirmasis baseinas yra underlay adresas, kurį operatorius davė modemu; jis turi likti už kiekvieno klientams skirto plano. Antrasis yra tunelio potinklis, kurį pasirinko serveris, dažnai jo paties privatus /24 potinklis. Trečiasis yra hotspot tiltas, o ketvirtasis yra namų prefiksas, kurį norite pasiekti. Šiame žingsnyje hotspot gauna 172.28.90.0/24 su tiltu 172.28.90.1, o namų paslaugų LAN išlaiko 192.168.77.0/24, o tai apeina vartotojų maršrutizatorių siūlomus 192.168.1.0/24 ir 10.0.0.0/24 numatytuosius bei operatoriaus diapazoną 100.64.0.0/10.

Hotspot DHCP diapazone skelbkite tik tilto adresą kaip vartus ir nieko daugiau. Niekada neduokite hotspot klientams namų adreso kaip vartų; jie neturi jungties lygio kelio į tą segmentą.

Maršrutizuokite kiekvieną kryptį toje pusėje, kuri ją valdo

Pi reikia maršruto į namų prefiksą per tunelį. Serveriai serverio režimu paprastai stumia tą maršrutą, todėl pirmiausia patvirtinkite, kad persiuntimas įjungtas ir kad branduolys išsprendžia namų adresą iš tun0.

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

Jei ip route get vis dar praneša apie underlay sąsają, sustokite ten; niekas toliau kelyje negali pataisyti neteisingos paieškos.

Namų įrenginiai neturi maršruto į 172.28.90.0/24, todėl jų atsakymai seka numatytuosius vartus ir miršta maršrutizatoriuje. Yra du palaikomi taisymai. Arba pridėkite statinį maršrutą namų maršrutizatoriuje, nukreipiantį hotspot prefiksą į VPN serverio LAN adresą, arba, kai serveris pats yra vartai, užregistruokite kliento prefiksą serverio pačio maršrutizavimo lentelėje. OpenVPN kelių klientų režimu klientui būdingas katalogas neša tą asociaciją: failas, pavadintas kliento sertifikato bendruoju vardu, kuriame yra iroute 172.28.90.0 255.255.255.0 ir atitinkama route eilutė, įdiegianti jį serverio branduolyje. Spėjamas branduolio maršrutas serveryje nėra tas pats teiginys kaip pasakyti serveriui, kuris klientas valdo prefiksą.

Neperkelkite namų tinklo DHCP paslaugos į VPN serverį, kad tai veiktų. Viso namo numatytųjų vartų pakeitimas yra daug didesnis pokytis nei vieno privataus grįžimo maršruto pridėjimas, ir jis įtraukia DNS, adresų rezervacijas ir kiekvieną įrenginį, kuris nepaiso naujos nuomos.

Atidarykite persiuntimą nespėliodami užkardos

Įjungtas persiuntimas nereiškia, kad paketui leidžiama praeiti. Srautas nuo tilto iki tunelio vis dar atsitrenkia į filtravimo taisykles, o numatytoji drop persiuntimo politika meta hotspot srautą, kol Pi savasis srautas tęsia darbą, o tai sukuria būtent aukščiau aprašytą skilusį simptomą.

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

Ieškokite priėmimo taisyklės nuo br0 iki tun0 ir atitinkamos atsakymo krypties, taip pat postrouting taisyklės, kuri gali perrašyti šaltinį. Jei grandinės politika yra drop ir nė viena taisyklė neatitinka, pridėkite siaurus priėmimus ir bandykite dar kartą, o ne apverskite politiką į accept.

Vertimas yra politikos pasirinkimas, o ne reikalavimas. Šaltinio NAT link namų LAN daro kiekvieną hotspot klientą panašų į Pi tunelio adresą, o tai praranda priskyrimą pagal klientą namų žurnaluose ir sugriauna paslaugas, kurios tikisi originalaus šaltinio. Maršrutizavimas be NAT išlaiko klientų adresus matomus, bet priklauso nuo aukščiau esančio grįžimo maršruto. Pasirinkite vieną ir su DNS bei IPv6 elkitės taip pat, nes veikiantis IPv4 kelias šalia sugedusio IPv6 kelio naršyklėje vis dar skaitomas kaip pusiau sugedęs.

Patikrinkite kelionę pirmyn ir atgal, tada tyčia ją sulaužykite

Testuokite iš hotspot kliento, niekada iš Pi, nes pats Pi srautas apeina ir pirmyn, ir grįžimo kelią. Stebėkite abi sąsajas, kol vienas klientas bando pasiekti namų paslaugą.

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

Skaitykite abu įrašus kartu. Užklausos br0, kurios niekada nepasirodo tun0, reiškia, kad Pi nepersiunčia arba maršrutas rodo kitur. Užklausos tun0 be atsakymų reiškia, kad namų pusėje nėra grįžimo maršruto arba serveris filtruoja paketą. Atsakymai tun0, kurie niekada nebepasirodo br0, reiškia, kad trūksta atvirkštinės filtravimo taisyklės, kai tunelis atrodo tobulas, o klientas vis tiek nieko nemato.

Tada tyčia sulaužykite kelią. Išjunkite modemo ryšį ir vėl įjunkite bei iš naujo paleiskite maršruto ir įrašymo patikras; maršrutas, kuris išgyvena tunelį, bet dingsta vėl prisijungus, priklauso ryšio profiliui, o ne vienkartinei komandai. Patvirtinkite, kad tunelio transportas vis dar išeina per underlay, o ne per save, klasikinė kilpa, kai stumiamas numatytasis maršrutas priimamas be maršruto į mazgą.

Priimkite dizainą tik tada, kai hotspot klientas gali išspręsti namų vardą, atidaryti TCP paslaugą ir išlaikyti sesiją gyvą per vieną modemo prisijungimą iš naujo. Jei programa tikrai reikalauja Ethernet lygio aptikimo namų segmente, pasirinkite palaikomą Layer 2 dizainą, o ne aprašykite vietinį tiltą kaip sujungtą ir laukite transliacijos.