Pi:n hotspot-asiakkaat eivät tavoita kodin LAN-verkkoa TUN-VPN:n kautta

Paikalliset Wi-Fi- ja Ethernet-asiakkaat liittyvät Pi:n hotspotiin, ottavat osoitteen sen DHCP-alueelta ja lataavat internetsivuja valittamatta. Samat asiakkaat sitten aikakatkaisevat, kun he avaavat tiedostohaun tai verkkokäyttöliittymän kodin LAN-verkossa, kun taas Pi itse tavoittaa tuon LAN-verkon tunnelin kautta. Langattomassa kerroksessa ei ole mitään rikki. Puuttuu reititetty sopimus: hotspotin etuliite on vietävä TUN-rajapintaan, ja jonkin kotipuolella on tiedettävä, miten vastaukset lähetetään sinne takaisin. Molempien puoliskojen on oltava olemassa, ennen kuin yksikään paketti voi suorittaa edestakaisen matkan.

Kolme liitosta, kolme eri tehtävää

Linuxin Ethernet-silta välittää kehyksiä kohde-MAC-osoitteen mukaan. OpenVPN TUN-tilassa kuljettaa IP-paketteja eikä sillä ole MAC-kerrosta lainkaan, joten paikallisen sillan lisääminen ei koskaan kirjaa tunnelia portiksi. ytimen TUN/TAP-dokumentaatio selittää tämän jaon: TAP-laite näyttää Ethernet-rajapinnalta, TUN-laite ei. Suunnittelu, joka siltaa kaksi paikallista porttia ja reitittää sitten, on reititin, mitä tahansa rajapintojen nimet sanovat.

Tuo ero ratkaisee omistajuuden. Asiakkaiden aliverkko, heidän oletusyhdyskäytävänsä ja tuon alueen DHCP-valtuus kuuluvat Pi:n paikalliseen suunnitelmaan. Kotiin tulevat DHCP-lähetykset eivät ylitä reititettyä tunnelia, eikä mikään siltä asetus muuta sitä; asiakkaiden osoittaminen kodin DHCP-palvelimelle on erillinen, tarkoituksellinen relay-suunnittelu omine vikatiloineen.

Pidä modeemi myös asiakassillan ulkopuolella. PPP-liitäntä ei ole erimerkkinen Ethernet-laite, ja pppd:n dokumentoitu oletusreitin logiikka toimii IPCP-neuvottelun jälkeen ja vetää reittinsä pois, kun tuo linkki katkeaa. DHCP-mallin kopioiminen ja jokaisen usb0-n nimeäminen ppp0-ksi ei todista mitään yhdyskäytävästä, metristä tai elinkaaresta.

Valitse etuliitteet ennen kuin muokkaat mitään konfiguraatiota

Päällekkäiset etuliitteet hukkaavat enemmän iltoja kuin palomuurisäännöt, koska päällekkäisyys lähettää reittihaun väärälle rajapinnalle silloinkin, kun tunneli on terve. Aloita listaamalla, mitä Pi:ssä on jo olemassa, ja lue tulos sitten neljänä erillisenä altaana.

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

Ensimmäinen allas on underlay-osoite, jonka operaattori antoi modeemille; sen on pysyttävä kaikkien asiakkaisiin päin olevien suunnitelmien ulkopuolella. Toinen on tunnelin aliverkko, jonka palvelin valitsi, usein oma yksityinen /24-verkko. Kolmas on hotspot-silta ja neljäs on kotietuliite, johon haluat päästä. Tässä läpikäynnissä hotspot saa 172.28.90.0/24 sillan ollessa 172.28.90.1, ja kodin palvelu-LAN pitää 192.168.77.0/24, mikä väistää kuluttajareitittimien mukana tulevat oletukset 192.168.1.0/24 ja 10.0.0.0/24 sekä operaattorin alueen 100.64.0.0/10.

Mainosta sillan osoitetta yhdyskäytävänä hotspotin DHCP-alueella ja vain sitä. Älä koskaan anna hotspot-asiakkaille kotiosoitetta yhdyskäytäväksi; heillä ei ole linkkikerroksen polkua tuohon segmenttiin.

Reititä kumpikin suunta sillä puolella, joka sen omistaa

Pi tarvitsee reitin kotietuliitteeseen tunnelin kautta. Palvelinmoodissa olevat palvelimet työntävät yleensä tuon reitin, joten varmista ensin, että edelleenlähetys on päällä ja että ydin ratkaisee kotiosoitteen tun0-sta.

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

Jos ip route get raportoi edelleen underlay-rajapinnan, pysähdy siihen; mikään polun myöhempi osa ei voi korjata väärää hakua.

Kodin laitteilla ei ole reittiä 172.28.90.0/24-een, joten niiden vastaukset seuraavat oletusyhdyskäytävää ja kuolevat reitittimeen. Kaksi tuettua korjausta on olemassa. Joko lisää kodin reitittimeen staattinen reitti, joka osoittaa hotspotin etuliitteen VPN-palvelimen LAN-osoitteeseen, tai kun palvelin itse on yhdyskäytävä, rekisteröi asiakkaan etuliite palvelimen omaan reititystauluun. OpenVPN:n moniasiakastilassa asiakaskohtainen hakemisto kantaa tämän liitoksen: tiedosto, joka on nimetty asiakkaan varmenteen yleisnimen mukaan ja sisältää iroute 172.28.90.0 255.255.255.0 sekä vastaavan route-rivin, joka asentaa sen palvelimen ytimeen. Palvelimella arvattu ydinreitti ei ole sama väite kuin kertoa palvelimelle, mikä asiakas omistaa etuliitteen.

Älä siirrä kodin verkon DHCP-palvelua VPN-palvelimelle, jotta tämä toimisi. Koko talon oletusyhdyskäytävän korvaaminen on paljon suurempi muutos kuin yhden yksityisen paluureitin lisääminen, ja se vetää DNS:n, osoitevaraukset ja jokaisen uuden vuokrasopimuksen sivuuttavan laitteen mukaan vikaan.

Avaa edelleenlähetys arvaamatta palomuuria

Edelleenlähetyksen päällä oleminen ei tarkoita, että paketti päästetään läpi. Liikenne sillalta tunneliin osuu yhä suodatinsääntöihin, ja oletuksena drop oleva edelleenlähetyskäytäntö pudottaa hotspot-liikenteen, kun Pi:n oma liikenne jatkaa toimimista, mikä tuottaa täsmälleen yllä kuvatun jakautuneen oireen.

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

Etsi hyväksyntäsääntö br0-sta tun0-een ja vastaava vastaussuunta sekä postrouting-sääntö, joka voi kirjoittaa lähteen uudelleen. Jos ketjun käytäntö on drop eikä mikään sääntö täsmää, lisää kapeat hyväksynnät ja testaa uudelleen sen sijaan, että kääntäisit käytännön acceptiksi.

Kääntäminen on käytäntövalinta, ei vaatimus. Lähde-NAT kodin LAN-verkkoa kohti saa jokaisen hotspot-asiakkaan näyttämään Pi:n tunneliosoitteelta, mikä menettää asiakaskohtaisen kohdistuksen kodin lokeissa ja rikkoo palveluita, jotka odottavat alkuperäistä lähdettä. Reititys ilman NAT:ia pitää asiakkaiden osoitteet näkyvinä mutta riippuu yllä olevasta paluureitistä. Valitse yksi ja käsittele DNS ja IPv6 samalla tavalla, koska toimiva IPv4-polku rikkinäisen IPv6-polun rinnalla luetaan selaimessa yhä puoliksi rikkinäiseksi.

Varmista edestakainen matka ja riko se sitten tarkoituksella

Testaa hotspot-asiakkaalta, älä koskaan Pi:stä, koska Pi:n oma liikenne ohittaa sekä meno- että paluupolun. Tarkkaile molempia rajapintoja, kun yksi asiakas yrittää tavoittaa kotipalvelun.

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

Lue molemmat tallenteet yhdessä. Pyynnöt br0-ssa, jotka eivät koskaan ilmesty tun0-een, tarkoittavat, että Pi ei välitä eteenpäin tai reitti osoittaa muualle. Pyynnöt tun0-ssa ilman vastauksia tarkoittavat, että kotipuolella ei ole paluureittiä tai palvelin suodatti paketin. Vastaukset tun0-ssa, jotka eivät koskaan ilmesty uudelleen br0-een, tarkoittavat, että käänteinen suodatinsääntö puuttuu, jolloin tunneli näyttää täydelliseltä ja asiakas ei silti näe mitään.

Riko sitten polku tarkoituksella. Laske modeemiyhteys alas ja takaisin ylös ja aja reitti- ja tallennustarkistukset uudelleen; reitti, joka selviää tunnelista mutta katoaa uudelleenyhdistettäessä, kuuluu yhteysprofiiliin, ei kertakäyttöiseen komentoon. Varmista, että tunnelin kuljetus lähtee edelleen underlayn kautta eikä sen itsensä kautta, klassinen silmukka, kun työnnetty oletusreitti hyväksytään ilman isäntäreittiä vertaiseen.

Hyväksy suunnittelu vain, kun hotspot-asiakas voi ratkaista kotinimen, avata TCP-palvelun ja pitää istunnon elossa yhden modeemin uudelleenyhdistämisen ajan. Jos sovellus todella vaatii Ethernet-tason löytämistä kotisegmentissä, valitse tuettu Layer 2 -suunnittelu sen sijaan, että kuvailisit paikallisen sillan siltana ja odottaisit lähetyksen ilmestymistä.