Pontita VPN-hotspot: kiun defaŭltan vojon uzas la telefono?
La defaŭlta vojo de la Pi ne estas la enirejo de la telefono. Apartigu la du decidojn, tenu la uplink ekster la ponto, kaj testu la luon antaŭ la tunelo.
La telefono ĉe via pontita hotspot ricevas sian adreson kaj sian enirejon de ie, kaj tio ne estas la defaŭlta vojo de la Pi. Ŝanĝi la defaŭlton de la Pi ŝanĝas, kien la Pi sendas sian propran trafikon. La telefono daŭre uzas la enirejon, pri kiu oni informis ĝin, kaj kiam tiu enirejo situas sur la fora LAN, ĝiaj kadroj simple transiras la ponton. Du konsumantoj, du decidoj. Apartigi ilin klarigas la plej multajn raportojn pri hotspot sen interreto dum la Pi mem estas en ordo.
Du aparatoj, du malsamaj decidoj pri enirejo
La Pi havas propran IP-stakon kaj propran defaŭltan vojon. La telefono havas propran IP-stakon kaj propran defaŭltan vojon.
| Consumer | Who chooses its gateway | What carries the traffic |
|---|---|---|
| Phone on the bridged AP | The remote LAN router, delivered in its client configuration | An Ethernet frame toward that router crosses the AP and TAP bridge |
| Pi's encrypted connection | The travel uplink's route toward the VPN peer | The Pi sends its own outer transport packets over the underlay |
Tiu tabelo estas la tuta modelo. La enirejo de la telefono estas adreso sur la fora LAN, kaj ĝiaj kadroj estas plusenditaj je tavolo 2 al tiu enkursigilo. La defaŭlta vojo de la Pi koncernas la propran eksteran transporton de la Pi, kiu devas atingi la VPN-parton super la vojaĝa uplink.
Ponto plusendas kadrojn, ĝi ne enkursigas pakaĵojn
Linux-ponto plusendas Ethernet-kadrojn laŭ cel-MAC, kaj tio estas ĉio, kion ĝi faras inter siaj havenoj. La kadro de la telefono adresita al la MAC de la fora enkursigilo estas ŝaltita al la TAP-haveno kaj transiras la tunelon sen tuŝi la enkursigan tabelon de la Pi. Tial rompita defaŭlta vojo de la Pi povas lasi la telefonon funkcii, kaj tial ĝusta ne povas ripari telefonon, kiu ricevis malĝustan enirejon.
TAP portas Ethernet-kadrojn kaj povas esti ponta haveno. TUN portas IP-pakaĵojn kaj ne povas. Se via dezajno anstataŭigis unu per la alia, la ponto ne estas ponto kaj la resto de ĉi tio ne validas.
Decidu, kiu disdonas la luon de la telefono
DHCP-opcio 3 estas la enkursigila opcio, kaj ĝi diras al la kliento, kiun enirejon uzi por sia subreto. Kiam la DHCP-servilo de la fora LAN estas la sola disdonanto, la telefono ricevas foran enirejon kaj la dezajno estas kohera. Kiam io alia sur la vojaĝa flanko respondas unue, la telefono ricevas lokan enirejon, ĝia interreta trafiko eliras per la vojaĝa uplink, kaj ĝia trafiko al la fora LAN havas tute neniun vojon.
Runu unu disdonanton por tiu dissenda domajno, kaj notu, kion ĝi disdonas.
La Pi estas aparta kazo eĉ kiam ĝi prenas adreson el la sama luo. Decidu konscie, ĉu ĝi instalos la vojojn, kiujn la luo proponas, ĉar importita fora defaŭlto povas treni la propran VPN-transporton de la Pi en la tunelon, kiun ĝi provas teni viva. Ĉe systemd-networkd tiu decido estas UseRoutes= en la DHCP-sekcio; ĉe dhclient ĝi estas la opcio routers en la petlisto.
Tenu la uplink ekster la pontita LAN
La interfaco, kiu portas la eksteran VPN-konekton de la Pi, ne rajtas fariĝi ponta haveno. Se ĝi fariĝas, la ĉifrita transporto estas ŝaltita en la etenditan LAN kaj la tunelo finas portante siajn proprajn eksterajn pakaĵojn, kio malsukcesas tiel, ke ĝi aspektas kiel perdo de pakaĵoj anstataŭ buklo. Tenu ankaŭ AP-kapablon kaj pontan subtenon eksplicitaj. Sendrata interfaco en station-reĝimo kutime ne povas esti ponta haveno, ĉar la 802.11-kapo ne havas lokon por la dua MAC-adreso, kiun ponto bezonas.
Difinu la etenditan dissendan domajnon, unu adresplanon kaj la kadran filtradon, kiun vi efektive volas. Permesi la VPN-aŭskultanton sur la Pi ne donas al ĉiu pontita kliento aliron al la administraj servoj de la Pi. Tiuj estas apartaj reguloj, kaj trakti ilin kiel unu estas kiel hotspot silente fariĝas malfermita pordo.
Testu la kvar aferojn aparte, kiam ĝi rompiĝas
Kiam la telefono ne povas atingi la foran LAN, kvar observoj apartigas la kaŭzojn. Rulu ilin en ĉi tiu ordo kaj haltu ĉe la unua, kiu malsukcesas.
ip route show default
bridge link show
ip -4 neigh show dev br0
tcpdump -ni br0 arp or icmpKomencu per la luo: ĉu la telefono tenas adreson kaj enirejon sur la fora subreto? Poste rigardu la ponton, kaj konfirmu, ke la AP-haveno kaj la TAP-haveno ambaŭ plusendas. Poste legu la najbaran tabelon, ĉar nesolvita rikordo por la fora enkursigilo signifas, ke kadroj foriras kaj nenio respondas. Fine observu kadrojn sur la ponto, dum la telefono pingas, kio diras al vi, ĉu la fuŝo estas tute sub IP.
Notu, kiu aparato posedas ĉiun defaŭlton, kiam vi finos. Unu linio da dokumentado igas lokan kontraŭ foran eliron konscia klienta decido, kaj la ponta referenco indas esti tenata apude.