Pi hotspot klienti nevar sasniegt mājas LAN caur TUN VPN

Vietējie Wi-Fi un Ethernet klienti pievienojas Pi hotspotam, saņem adresi no tā DHCP diapazona un ielādē interneta lapas bez sūdzībām. Pēc tam šie paši klienti nokļūst laika limitā, atverot failu koplietojumu vai tīmekļa saskarni mājas LAN, kamēr pats Pi sasniedz šo LAN caur tuneli. Bezvadu slānī nekas nav salauzts. Trūkst maršrutēta līguma: hotspot prefikss jāpārvieto uz TUN saskarni, un kaut kam mājas pusē jāzina, kā sūtīt atbildes atpakaļ. Abām pusēm jābūt, pirms viens pakets var pabeigt ceļu turp un atpakaļ.

Trīs savienojumi ar trim dažādiem uzdevumiem

Linux Ethernet tilts pārsūta kadrus pēc galamērķa MAC adreses. OpenVPN TUN režīmā pārvadā IP paketes un tam vispār nav MAC slāņa, tāpēc lokāla tilta pievienošana nekad nereģistrē tuneli kā portu. kodola TUN/TAP dokumentācija izskaidro šo atdalījumu: TAP ierīce izskatās kā Ethernet saskarne, TUN ierīce — nē. Dizains, kas savieno divus lokālus portus un pēc tam maršrutē, ir maršrutētājs, lai ko teiktu saskarņu nosaukumi.

Šī atšķirība nosaka īpašumtiesības. Klientu apakštīkls, to noklusējuma vārteja un šī diapazona DHCP pilnvaras pieder Pi vietējam plānam. Mājas DHCP apraides nešķērso maršrutētu tuneli, un neviens tilta iestatījums to nemaina; klientu novirzīšana uz mājas DHCP serveri ir atsevišķs, apzināts relay dizains ar saviem kļūmes režīmiem.

Turiet modemu arī ārpus klientu tilta. PPP savienojums nav Ethernet ierīce ar citu etiķeti, un pppd dokumentētā noklusējuma maršruta loģika darbojas pēc IPCP sarunām un atsauc savu maršrutu, kad šis savienojums krīt. DHCP veidnes kopēšana un katra usb0 pārdēvēšana par ppp0 neko nepierāda par vārteju, metriku vai dzīves ciklu.

Izvēlieties prefiksus pirms jebkuras konfigurācijas rediģēšanas

Pārklājošies prefiksi izšķiež vairāk vakaru nekā ugunsmūra noteikumi, jo pārklāšanās nosūta maršruta meklēšanu uz nepareizo saskarni pat tad, kad tunelis ir vesels. Sāciet ar to, kas Pi jau ir, un pēc tam lasiet rezultātu kā četrus atsevišķus baseinus.

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

Pirmais baseins ir underlay adrese, ko operators deva modemam; tai jāpaliek ārpus katra klientiem vērsta plāna. Otrais ir tuneļa apakštīkls, ko izvēlējās serveris, bieži tā paša privātais /24-tīkls. Trešais ir hotspot tilts, un ceturtais ir mājas prefikss, kuru vēlaties sasniegt. Šajā gaitā hotspots iegūst 172.28.90.0/24 ar tiltu uz 172.28.90.1, un mājas pakalpojumu LAN saglabā 192.168.77.0/24, kas apiet patērētāju maršrutētāju piegādātos noklusējumus 192.168.1.0/24 un 10.0.0.0/24 un operatora diapazonu 100.64.0.0/10.

Hotspot DHCP diapazonā kā vārteju reklamējiet tikai tilta adresi un neko citu. Nekad nedodiet hotspot klientiem mājas adresi kā vārteju; viņiem nav savienojuma līmeņa ceļa uz šo segmentu.

Maršrutējiet katru virzienu tajā pusē, kurai tas pieder

Pi vajag maršrutu uz mājas prefiksu caur tuneli. Serveri servera režīmā parasti spiež šo maršrutu, tāpēc vispirms pārliecinieties, ka pārsūtīšana ir ieslēgta un ka kodols atrisina mājas adresi no tun0.

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

Ja ip route get joprojām ziņo par underlay saskarni, apstājieties tur; nekas tālāk ceļā nevar salabot nepareizu meklēšanu.

Mājas ierīcēm nav maršruta uz 172.28.90.0/24, tāpēc to atbildes seko noklusējuma vārtejai un mirst maršrutētājā. Ir divi atbalstīti labojumi. Vai nu pievienojiet statisku maršrutu mājas maršrutētājā, kas vērš hotspot prefiksu uz VPN servera LAN adresi, vai, ja serveris pats ir vārteja, reģistrējiet klienta prefiksu servera paša maršrutēšanas tabulā. OpenVPN daudzklientu režīmā klientam raksturīgā direktorija nes šo saistību: fails, nosaukts pēc klienta sertifikāta vispārīgā nosaukuma, kurā ir iroute 172.28.90.0 255.255.255.0 un atbilstošā route rinda, kas to instalē servera kodolā. Uzminēts kodola maršruts serverī nav tas pats apgalvojums kā pateikt serverim, kurš klients pieder prefiksu.

Nepārvietojiet mājas tīkla DHCP pakalpojumu uz VPN serveri, lai tas darbotos. Visas mājas noklusējuma vārtejas nomaiņa ir daudz lielāka izmaiņa nekā viena privāta atgriešanās maršruta pievienošana, un tā ievelk DNS, adrešu rezervācijas un katru ierīci, kas ignorē jauno nomu, kļūmē.

Atveriet pārsūtīšanu, neuzminot ugunsmūri

Ieslēgta pārsūtīšana nenozīmē, ka paketam atļauts iziet. Satiksme no tilta uz tuneli joprojām saduras ar filtra noteikumiem, un noklusējuma drop pārsūtīšanas politika izmet hotspot satiksmi, kamēr Pi paša satiksme turpina darboties, kas rada tieši iepriekš aprakstīto sadalīto simptomu.

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

Meklējiet atļaušanas noteikumu no br0 uz tun0 un atbilstošo atbildes virzienu, kā arī postrouting noteikumu, kas var pārrakstīt avotu. Ja ķēdes politika ir drop un neviens noteikums neatbilst, pievienojiet šauros atļaušanas noteikumus un testējiet vēlreiz, nevis pagrieziet politiku uz accept.

Tulkošana ir politikas izvēle, nevis prasība. Avota NAT pret mājas LAN liek katram hotspot klientam izskatīties kā Pi tuneļa adresei, kas zaudē piesaisti katram klientam mājas žurnālos un salauž pakalpojumus, kas gaida sākotnējo avotu. Maršrutēšana bez NAT saglabā klientu adreses redzamas, bet ir atkarīga no iepriekš minētā atgriešanās maršruta. Izvēlieties vienu un apstrādājiet DNS un IPv6 tāpat, jo strādājošs IPv4 ceļš blakus salauztam IPv6 ceļam pārlūkā joprojām lasās kā puslīdz salauzts.

Pārbaudiet ceļu turp un atpakaļ, pēc tam apzināti salauziet to

Testējiet no hotspot klienta, nekad no Pi, jo Pi paša satiksme apiet gan uz priekšu, gan atgriešanās ceļu. Vērojiet abas saskarnes, kamēr viens klients mēģina sasniegt mājas pakalpojumu.

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

Lasiet abus ierakstus kopā. Pieprasījumi uz br0, kas nekad neparādās uz tun0, nozīmē, ka Pi nepārsūta vai maršruts rāda citur. Pieprasījumi uz tun0 bez atbildēm nozīmē, ka mājas pusei nav atgriešanās maršruta vai serveris filtrēja paketi. Atbildes uz tun0, kas nekad vairs neparādās uz br0, nozīmē, ka trūkst apgrieztā filtra noteikuma, kur tunelis izskatās ideāls un klients joprojām neredz neko.

Pēc tam apzināti salauziet ceļu. Izslēdziet modema savienojumu un ieslēdziet to atpakaļ un atkārtoti izpildiet maršruta un ieraksta pārbaudes; maršruts, kas pārdzīvo tuneli, bet pazūd atkārtotā savienojumā, pieder savienojuma profilam, nevis vienreizējai komandai. Pārliecinieties, ka tuneļa transports joprojām iziet caur underlay, nevis caur sevi, klasiskā cilpa, kad tiek pieņemts uzspiests noklusējuma maršruts bez maršruta uz resursdatoru.

Pieņemiet dizainu tikai tad, kad hotspot klients var atrisināt mājas nosaukumu, atvērt TCP pakalpojumu un noturēt sesiju dzīvu vienā modema atkārtotā savienojumā. Ja lietojumprogrammai patiešām nepieciešama Ethernet līmeņa atklāšana mājas segmentā, izvēlieties atbalstītu Layer 2 dizainu, nevis aprakstiet lokālo tiltu kā savienotu un gaidiet apraidi.