Hotspot klijenti na Pi-ju ne mogu doći do kućne LAN mreže preko TUN VPN-a

Lokalni Wi-Fi i Ethernet klijenti povezuju se na Pi-jev hotspot, uzimaju adresu iz njegovog DHCP opsega i učitavaju internet stranice bez prigovora. Ti isti klijenti zatim isteknu kad otvore dijeljenje datoteka ili web sučelje na kućnoj LAN mreži, dok sam Pi dolazi do te LAN mreže preko tunela. Ništa u bežičnom sloju nije pokvareno. Nedostaje rutirana pogodba: hotspot prefiks mora se prenijeti u TUN sučelje, a nešto na kućnoj strani mora znati kako poslati odgovore natrag. Obje polovine moraju postojati prije nego što jedan paket može završiti povratno putovanje.

Tri priključka s tri različita posla

Linux Ethernet most prosljeđuje okvire prema odredišnoj MAC adresi. OpenVPN u TUN načinu nosi IP pakete i uopće nema MAC sloj, pa dodavanje lokalnog mosta nikada ne upisuje tunel kao port. dokumentacija kernela za TUN/TAP objašnjava tu podjelu: TAP uređaj izgleda kao Ethernet sučelje, a TUN uređaj ne. Dizajn koji premosti dva lokalna porta pa rutira jest ruter, kako god se sučelja zvala.

Ta razlika rješava vlasništvo. Klijentska podmreža, njihov zadani gateway i DHCP ovlast za taj opseg pripadaju lokalnom planu Pi-ja. Kućni DHCP broadcasti ne prelaze rutirani tunel i nijedna postavka mosta to ne mijenja; usmjeravanje klijenata na kućni DHCP poslužitelj zaseban je, namjerni relay dizajn s vlastitim načinima kvara.

Držite modem i izvan klijentskog mosta. PPP priključak nije Ethernet uređaj s drugom naljepnicom, a pppd-ova dokumentirana logika zadane rute radi nakon IPCP pregovora i povlači svoju rutu kad taj link padne. Kopiranje DHCP predloška i preimenovanje svakog usb0 u ppp0 ne dokazuje ništa o gatewayu, metrici ili životnom ciklusu.

Odaberite prefikse prije nego uredite bilo koju konfiguraciju

Prefiksi koji se preklapaju troše više večeri od pravila vatrozida, jer preklapanje šalje pretragu rute na pogrešno sučelje čak i kad je tunel zdrav. Počnite popisom onoga što već postoji na Pi-ju, pa rezultat čitajte kao četiri odvojena bazena.

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

Prvi bazen je underlay adresa koju je operater dao modemu; mora ostati izvan svakog plana okrenutog klijentima. Drugi je tunelska podmreža koju je odabrao poslužitelj, često vlastita privatna /24 mreža. Treći je hotspot most, a četvrti je kućni prefiks koji želite dosegnuti. U ovom prolazu hotspot dobiva 172.28.90.0/24 s mostom na 172.28.90.1, a kućna servisna LAN zadržava 192.168.77.0/24, što zaobilazi zadane 192.168.1.0/24 i 10.0.0.0/24 koje dolaze s potrošačkim ruterima i operaterski raspon 100.64.0.0/10.

Oglašavajte adresu mosta kao gateway u DHCP opsegu hotspota i ništa drugo. Nikada ne dajite hotspot klijentima kućnu adresu kao gateway; oni nemaju put na razini linka do tog segmenta.

Rutirajte svaki smjer na strani koja ga posjeduje

Pi-ju treba ruta za kućni prefiks kroz tunel. Poslužitelji u serverskom načinu obično guraju tu rutu, pa prvo potvrdite da je prosljeđivanje uključeno i da kernel razrješava kućnu adresu iz tun0.

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

Ako ip route get još izvještava underlay sučelje, zaustavite se tu; ništa dalje na putu ne može popraviti pogrešnu pretragu.

Kućni uređaji nemaju rutu do 172.28.90.0/24, pa njihovi odgovori slijede zadani gateway i umiru na ruteru. Postoje dva podržana popravka. Ili dodajte statičnu rutu na kućnom ruteru koja hotspot prefiks usmjerava na LAN adresu VPN poslužitelja, ili, kad je poslužitelj sam gateway, registrirajte klijentski prefiks u vlastitoj tablici usmjeravanja poslužitelja. U OpenVPN-ovom višeklijentskom načinu klijentski direktorij nosi tu vezu: datoteka nazvana po uobičajenom imenu klijentskog certifikata, koja sadrži iroute 172.28.90.0 255.255.255.0 plus odgovarajući route redak koji ga instalira u kernel poslužitelja. Nagađana kernel ruta na poslužitelju nije ista izjava kao reći poslužitelju koji klijent posjeduje prefiks.

Ne premještajte DHCP uslugu kućne mreže na VPN poslužitelj da bi ovo radilo. Zamjena zadanog gatewaya za cijelu kuću mnogo je veća promjena od dodavanja jedne privatne povratne rute i uvlači DNS, rezervacije adresa i svaki uređaj koji ignorira novi najam u kvar.

Otvorite prosljeđivanje bez nagađanja vatrozida

Uključeno prosljeđivanje ne znači da je paket dopušten. Promet s mosta prema tunelu još udara u filtrirajuća pravila, a zadana drop politika prosljeđivanja odbacuje hotspot promet dok Pi-jev vlastiti promet nastavlja raditi, što proizvodi točno gore opisani podijeljeni simptom.

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

Tražite pravilo prihvaćanja od br0 prema tun0 i odgovarajući smjer odgovora, te postrouting pravilo koje može prepisati izvor. Ako je politika lanca drop i nijedno pravilo ne odgovara, dodajte uska prihvaćanja i ponovno testirajte umjesto prebacivanja politike na accept.

Prevođenje je odabir politike, a ne zahtjev. Izvorni NAT prema kućnoj LAN mreži čini svakog hotspot klijenta sličnim Pi-jevom tunelskom addressu, što gubi atribuciju po klijentu u kućnim zapisima i kvari usluge koje očekuju izvorni izvor. Rutiranje bez NAT-a drži klijentske adrese vidljivima, ali ovisi o povratnoj ruti gore. Odaberite jedno i tretirajte DNS i IPv6 na isti način, jer radna IPv4 putanja uz pokvarenu IPv6 putanju još se čita kao napola pokvarena u pregledniku.

Provjerite povratno putovanje, pa ga namjerno pokvarite

Testirajte s hotspot klijenta, nikada s Pi-ja, jer Pi-jev vlastiti promet zaobilazi i put naprijed i povratni put. Promatrajte oba sučelja dok jedan klijent pokušava dosegnuti kućnu uslugu.

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

Čitajte dva snimka zajedno. Zahtjevi na br0 koji se nikad ne pojave na tun0 znače da Pi ne prosljeđuje ili ruta pokazuje drugamo. Zahtjevi na tun0 bez odgovora znače da kućna strana nema povratnu rutu ili je poslužitelj filtrirao paket. Odgovori na tun0 koji se nikad ne pojave ponovno na br0 znače da nedostaje obrnuto pravilo filtriranja, gdje tunel izgleda savršeno, a klijent još ne vidi ništa.

Zatim namjerno pokvarite put. Spustite modem vezu i ponovno je podignite te ponovno pokrenite provjere rute i snimke; ruta koja preživi tunel ali nestane pri ponovnom spajanju pripada profilu veze, a ne jednokratnoj naredbi. Potvrdite da promet tunela još izlazi kroz underlay, a ne kroz sebe, klasična petlja kad se gurnuta zadana ruta prihvati bez host rute do partnera.

Prihvatite dizajn samo kad hotspot klijent može razriješiti kućno ime, otvoriti TCP uslugu i održati sesiju živom kroz jedno ponovno spajanje modema. Ako aplikacija doista zahtijeva otkrivanje na Ethernet razini u kućnom segmentu, odaberite podržani Layer 2 dizajn umjesto da lokalni most opisujete kao premosćen i čekate da se pojavi broadcast.