Hotspot-klientoj sur Pi ne atingas la hejman LAN tra TUN-VPN

Hotspot-klientoj, kiuj ricevas adreson sed ne povas malfermi hejman kunhavigon, mankas al ili revena vojo, ne ponto. Spuru la TUN-vojon, posedantojn de prefiksoj kaj NAT.

Lokaj Wi-Fi kaj Ethernet-klientoj aliĝas al la hotspot de la Pi, prenas adreson el sia DHCP-gamo kaj ŝargas retpaĝojn sen plendo. Tiuj samaj klientoj poste tempolimas kiam ili malfermas dosierkunhavigon aŭ retan interfacon en la hejma LAN, dum la Pi mem atingas tiun LAN tra la tunelo. Nenio en la sendrata tavolo estas rompita. Mankas enkursigita kontrakto: la hotspot-prefikso devas esti portata en la TUN-interfacon, kaj io sur la hejma flanko devas scii kiel sendi respondojn reen al ĝi. Ambaŭ duonoj devas ekzisti antaŭ ol unu paketo povas fini la rondon.

Tri alkroĉoj kun tri malsamaj taskoj

Linux-Ethernet-ponto plusendas kadrojn laŭ la celloka MAC-adreso. OpenVPN en TUN-reĝimo portas IP-paketojn kaj tute ne havas MAC-tavolon, do aldoni lokan ponton neniam enskribas la tunelon kiel pordon. La kerna dokumentaro pri TUN/TAP klarigas tiun dividon: TAP-aparato aspektas kiel Ethernet-interfaco, TUN-aparato ne. Dezajno, kiu pontas du lokajn pordojn kaj poste enkursigas, estas enkursigilo, kion ajn diras la interfacaj nomoj.

Tiu distingo decidas posedrajton. La subreto de la klientoj, ilia defaŭlta pordego kaj la DHCP-aŭtoritato por tiu gamo apartenas al la loka plano de la Pi. Hejmaj DHCP-elsendoj ne transiras enkursigitan tunelon, kaj neniu pontagordo tion ŝanĝas; direkti la klientojn al hejma DHCP-servilo estas aparta, intenca relajsa dezajno kun propraj fiaskmanieroj.

Tenu la modemon ankaŭ ekster la klienta ponto. PPP-alkroĉo ne estas Ethernet-aparato kun alia etikedo, kaj la dokumentita defaŭlta enkursiga logiko de pppd funkcias post IPCP-intertraktado kaj retiras sian vojon kiam tiu ligo falas. Kopii DHCP-ŝablonon kaj renomi ĉiun usb0 al ppp0 pruvas nenion pri pordego, metriko aŭ vivociklo.

Elektu la prefiksojn antaŭ ol redakti ajnan agordon

Interkovrantaj prefiksoj perdas pli da vesperoj ol fajroŝirmilaj reguloj, ĉar interkovro sendas la vojserĉon al la malĝusta interfaco eĉ kiam la tunelo estas sana. Komencu listigante tion, kio jam ekzistas sur la Pi, poste legu la rezulton kiel kvar apartaj naĝejoj.

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

La unua naĝejo estas la underlay-adreso, kiun la operatoro donis al la modemo; ĝi devas resti ekster ĉiu klientfrunta plano. La dua estas la tunela subreto, kiun la servilo elektis, ofte propra privata /24-reto. La tria estas la hotspot-ponto, kaj la kvara estas la hejma prefikso, kiun vi volas atingi. En ĉi tiu trairo la hotspot ricevas 172.28.90.0/24 kun la ponto ĉe 172.28.90.1, kaj la hejma serva LAN retenas 192.168.77.0/24, kio evitas la defaŭltojn 192.168.1.0/24 kaj 10.0.0.0/24, kiujn konsumantaj enkursigiloj venas kun, kaj la operatoran gamon 100.64.0.0/10.

Anoncu la pontan adreson kiel pordego en la DHCP-gamo de la hotspot kaj nenion alian. Neniam donu al hotspot-klientoj hejman adreson kiel pordegon; ili havas neniun ligtavolan vojon al tiu segmento.

Enkursigu ĉiun direkton sur la flanko, kiu posedas ĝin

La Pi bezonas vojon por la hejma prefikso tra la tunelo. Serviloj en servila reĝimo kutime puŝas tiun vojon, do unue konfirmu ke plusendado estas ŝaltita kaj ke la kerno solvas hejman adreson el tun0.

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

Se ip route get ankoraŭ raportas la underlay-interfacon, haltu tie; nenio pli malsupre en la vojo povas ripari malĝustan serĉon.

Hejmaj aparatoj havas neniun vojon al 172.28.90.0/24, do iliaj respondoj sekvas la defaŭltan pordegon kaj mortas ĉe la enkursigilo. Ekzistas du subtenataj riparoj. Aŭ aldonu statikan vojon sur la hejma enkursigilo, kiu direktas la hotspot-prefikson al la LAN-adreso de la VPN-servilo, aŭ, kiam la servilo mem estas la pordego, registru la klientan prefikson en la propra enkursiga tabelo de la servilo. En la plurklients reĝimo de OpenVPN la klient-specifa dosierujo portas tiun asociadon: dosiero nomita laŭ la komuna nomo de la klienta atestilo, enhavanta iroute 172.28.90.0 255.255.255.0 plus la respondan route-linion, kiu instalas ĝin en la servila kerno. Divenita kerna vojo sur la servilo ne estas la sama aserto kiel diri al la servilo, kiu kliento posedas la prefikson.

Ne movu la DHCP-servon de la hejma reto al la VPN-servilo por igi ĉi tion funkcii. Anstataŭigi la defaŭltan pordegon por tuta domo estas multe pli granda ŝanĝo ol aldoni unu privatan revenan vojon, kaj ĝi trenas DNS, adresrezervojn kaj ĉiun aparaton, kiu ignoras la novan luon, en la fiaskon.

Malfermu plusendadon sen diveni la fajroŝirmilon

Ŝaltita plusendado ne signifas, ke la paketo rajtas pasi. Trafiko de la ponto al la tunelo ankoraŭ trafas la filtrajn regulojn, kaj defaŭlta drop-plusenda politiko faligas hotspot-trafikon dum la propra trafiko de la Pi daŭre funkcias, kio produktas ĝuste la fenditan simptomon supre.

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

Serĉu akceptan regulon de br0 al tun0 kaj la respondan direkton, kaj postrouting-regulon, kiu povas reverki la fonton. Se la ĉena politiko estas drop kaj neniu regulo kongruas, aldonu la mallarĝajn akceptojn kaj retestu anstataŭ turni la politikon al accept.

Tradukado estas politika elekto, ne postulo. Fonta NAT al la hejma LAN igas ĉiun hotspot-klienton aspekti kiel la tunela adreso de la Pi, kio perdas klient-post-klientan atribuon en hejmaj protokoloj kaj rompas servojn, kiuj atendas la originan fonton. Enkursigado sen NAT tenas klientajn adresojn videblaj sed dependas de la revena vojo supre. Elektu unu kaj traktu DNS kaj IPv6 same, ĉar funkcianta IPv4-vojo apud rompita IPv6-vojo ankoraŭ legiĝas kiel duone rompita en retumilo.

Kontrolu la rondon, poste rompu ĝin intence

Testu de hotspot-kliento, neniam de la Pi, ĉar la propra trafiko de la Pi preteriras kaj la antaŭan kaj la revenan vojon. Observu ambaŭ interfacojn dum unu kliento provas atingi hejman servon.

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

Legu la du registraĵojn kune. Petoj sur br0, kiuj neniam aperas sur tun0, signifas, ke la Pi ne plusendas aŭ la vojo montras aliloken. Petoj sur tun0 sen respondoj signifas, ke la hejma flanko havas neniun revenan vojon aŭ la servilo filtris la paketon. Respondoj sur tun0, kiuj neniam reaperas sur br0, signifas, ke la inversa filtra regulo mankas, kie la tunelo aspektas perfekta kaj la kliento tamen vidas nenion.

Poste rompu la vojon intence. Mallevu la modeman konekton kaj relevu ĝin kaj rerulu la vojajn kaj registrajn kontrolojn; vojo, kiu postvivas la tunelon sed malaperas ĉe rekonekto, apartenas al la konekta profilo, ne al unufoja komando. Konfirmu, ke la transporto de la tunelo ankoraŭ eliras tra la underlay kaj ne tra si mem, la klasika buklo kiam puŝita defaŭlta vojo akceptiĝas sen gastiga vojo al la samtavolano.

Akceptu la dezajnon nur kiam hotspot-kliento povas solvi hejman nomon, malfermi TCP-servon kaj teni sesion viva tra unu modema rekonekto. Se aplikaĵo vere postulas Ethernet-nivelan malkovron sur la hejma segmento, elektu subtenatan Layer 2-dezajnon anstataŭ priskribi la lokan ponton kiel pontitan kaj atendi elsendon.

Rilataj artikoloj