Odjemalci na dostopni točki Pi ne dosežejo domačega LAN prek VPN TUN

Lokalni odjemalci Wi-Fi in Ethernet se povežejo z dostopno točko Pi, dobijo naslov iz njenega obsega DHCP in nalagajo internetne strani brez pritožb. Istim odjemalcem nato poteče čas, ko odprejo skupno rabo datotek ali spletni vmesnik v domačem LAN, medtem ko Pi sam doseže ta LAN prek tunela. V brezžičnem sloju ni nič pokvarjeno. Manjka usmerjena pogodba: predpono dostopne točke je treba prenesti v vmesnik TUN, in nekaj na domači strani mora vedeti, kako poslati odgovore nazaj. Obe polovici morata obstajati, preden lahko en paket zaključi pot tja in nazaj.

Tri povezave s tremi različnimi nalogami

Vmesnik Ethernet most v Linuxu posreduje okvire glede na ciljni naslov MAC. OpenVPN v načinu TUN prenaša pakete IP in sploh nima plasti MAC, zato dodajanje lokalnega mostu nikoli ne vpiše tunela kot vrat. dokumentacija jedra o TUN/TAP pojasnjuje to ločitev: naprava TAP je videti kot vmesnik Ethernet, naprava TUN ne. Zasnova, ki premosti dve lokalni vrati in nato usmerja, je usmerjevalnik, kar koli pravijo imena vmesnikov.

Ta razlika odloči lastništvo. Podomrežje odjemalcev, njihova privzeta prehodna postaja in pooblastilo DHCP za to območje pripadajo lokalnemu načrtu Pi. Domače oddaje DHCP ne prečkajo usmerjenega tunela in nobena nastavitev mostu tega ne spremeni; usmerjanje odjemalcev na domači strežnik DHCP je ločena, namerna zasnova posredovanja z lastnimi načini odpovedi.

Tudi modem držite zunaj odjemalskega mostu. Povezava PPP ni naprava Ethernet z drugo oznako, in dokumentirana logika privzete poti v pppd teče po pogajanju IPCP ter umakne svojo pot, ko ta povezava pade. Kopiranje predloge DHCP in preimenovanje vsakega usb0 v ppp0 ne dokazuje ničesar o prehodni postaji, metriki ali življenjskem ciklu.

Izberite predpone, preden uredite katero koli konfiguracijo

Prekrivajoče se predpone zapravijo več večerov kot pravila požarnega zidu, ker prekrivanje pošlje iskanje poti na napačen vmesnik tudi ko je tunel zdrav. Začnite s seznamom tega, kar na Pi že obstaja, nato rezultat berite kot štiri ločene bazene.

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

Prvi bazen je naslov underlay, ki ga je operater dal modemu; ostati mora zunaj vsakega načrta, obrnjenega k odjemalcem. Drugi je podomrežje tunela, ki ga je izbral strežnik, pogosto njegov lastni zasebni /24 omrežje. Tretji je most dostopne točke, četrti pa domača predpona, ki jo želite doseči. Na tej poti dobi dostopna točka 172.28.90.0/24 z mostom na 172.28.90.1, domači storitveni LAN pa obdrži 192.168.77.0/24, kar se izogne privzetima 192.168.1.0/24 in 10.0.0.0/24, ki ju prinašajo potrošniški usmerjevalniki, in operaterskemu obsegu 100.64.0.0/10.

V obsegu DHCP dostopne točke kot prehodno postajo oglašujte samo naslov mostu in nič drugega. Odjemalcem dostopne točke nikoli ne dajte domačega naslova kot prehodne postaje; nimajo poti na povezavni plasti do tega segmenta.

Usmerjajte vsako smer na strani, ki jo ima v lasti

Pi potrebuje pot do domače predpone skozi tunel. Strežniki v strežniškem načinu običajno potiskajo to pot, zato najprej potrdite, da je posredovanje vklopljeno in da jedro razreši domači naslov 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

Če ip route get še vedno poroča o vmesniku underlay, se ustavite tam; nič dlje na poti ne more popraviti napačnega iskanja.

Domače naprave nimajo poti do 172.28.90.0/24, zato njihovi odgovori sledijo privzeti prehodni postaji in umrejo na usmerjevalniku. Obstajata dve podprti popravili. Bodisi dodajte statično pot na domačem usmerjevalniku, ki usmeri predpono dostopne točke na naslov LAN strežnika VPN, bodisi, ko je strežnik sam prehodna postaja, registrirajte predpono odjemalca v lastni usmerjevalni tabeli strežnika. V načinu z več odjemalci OpenVPN nosi mapo, specifično za odjemalca, to povezavo: datoteka, poimenovana po splošnem imenu potrdila odjemalca, ki vsebuje iroute 172.28.90.0 255.255.255.0 in ustrezno vrstico route, ki jo namesti v jedro strežnika. Ugibana pot jedra na strežniku ni ista izjava kot povedati strežniku, kateri odjemalec ima predpono v lasti.

Storitve DHCP domačega omrežja ne premaknite na strežnik VPN, da bi to delovalo. Zamenjava privzete prehodne postaje za celo hišo je veliko večja sprememba kot dodajanje ene zasebne povratne poti in v odpoved potegne DNS, rezervacije naslovov in vsako napravo, ki ignorira novi najem.

Odprite posredovanje, ne da bi ugibali o požarnem zidu

Vklopljeno posredovanje ne pomeni, da sme paket skozi. Promet z mostu v tunel še vedno zadene pravila filtriranja, privzeta politika posredovanja drop pa zavrže promet dostopne točke, medtem ko lastni promet Pi deluje naprej, kar ustvari natanko razcepljeni simptom zgoraj.

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

Iščite pravilo sprejema od br0 do tun0 in ustrezno smer odgovora ter pravilo postrouting, ki lahko prepiše vir. Če je politika verige drop in nobeno pravilo ne ustreza, dodajte ozke sprejeme in znova preizkusite, namesto da bi politiko obrnili v accept.

Prevajanje je izbira politike, ne zahteva. Izvorni NAT proti domačemu LAN naredi vsakega odjemalca dostopne točke videti kot naslov tunela Pi, kar izgubi pripis po odjemalcih v domačih dnevnikih in pokvari storitve, ki pričakujejo izvirni vir. Usmerjanje brez NAT ohrani naslove odjemalcev vidne, a je odvisno od povratne poti zgoraj. Izberite eno in z DNS ter IPv6 ravnajte enako, ker se delujoča pot IPv4 ob pokvarjeni poti IPv6 v brskalniku še vedno bere kot napol pokvarjena.

Preverite pot tja in nazaj, nato jo namerno pokvarite

Preizkusite z odjemalca dostopne točke, nikoli s Pi, ker lastni promet Pi obide tako pot naprej kot povratno pot. Opazujte oba vmesnika, ko en odjemalec poskuša doseči domačo storitev.

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

Berite oba posnetka skupaj. Zahteve na br0, ki se nikoli ne pojavijo na tun0, pomenijo, da Pi ne posreduje ali da pot kaže drugam. Zahteve na tun0 brez odgovorov pomenijo, da domača stran nima povratne poti ali da je strežnik paket filtriral. Odgovori na tun0, ki se nikoli več ne pojavijo na br0, pomenijo, da manjka obratno pravilo filtriranja, kjer je tunel videti popoln, odjemalec pa še vedno ne vidi ničesar.

Nato pot namerno pokvarite. Spustite modemsko povezavo in jo znova dvignite ter znova zaženite preverjanja poti in posnetkov; pot, ki preživi tunel, a ob ponovni povezavi izgine, sodi v profil povezave, ne v enkratni ukaz. Potrdite, da promet tunela še vedno izhaja skozi underlay in ne skozi samega sebe, klasična zanka, ko je potisnjena privzeta pot sprejeta brez poti do gostitelja pri partnerju.

Zasnovo sprejmite le, ko lahko odjemalec dostopne točke razreši domače ime, odpre storitev TCP in ohrani sejo živo skozi eno ponovno povezavo modema. Če aplikacija resnično potrebuje odkrivanje na ravni Ethernet v domačem segmentu, izberite podprto zasnovo Layer 2, namesto da lokalni most opisujete kot premosti in čakate na oddajo.