Kial ĵetado ĉesas funkcii post ŝalto de la enkursigna VPN
Malkovro iras per loka multicast, dum la televidilo mem elŝutas la amaskomunikilojn. Defaŭlta politiko povas kapti la peton de la loka reto kaj sendi ĝin en la tunelon.
Ĵetado funkciis antaŭ ol la enkursigna VPN estis ŝaltita kaj fiaskas tuj poste, dum ordinara retumado en la telefono ankoraŭ funkcias. La du faktoj kongruas, ĉar ĵetado ne estas unu konekto. La telefono malkovras kaj regas la ricevilon tra la loka reto, kaj la ricevilo poste elŝutas la amaskomunikilojn tra sia propra konekto.
Du vojoj, kiuj fiaskas malsame
La rega vojo estas loka. Telefono trovas ricevilon per demando al la loka reto, poste malfermas regan konekton al la adreso, kiun ĝi lernis. Se la ricevilo neniam aperas en la listo, la malkovra paŝo fiaskis antaŭ ol petiĝis ajna amaskomunikilo.
La vojo de la amaskomunikiloj ne nepre estas loka. Multaj riceviloj mem elŝutas la fluon, tra sia propra konekto kaj kun siaj propraj akreditaĵoj, do la vojo de la telefono ne priskribas la vojon de la ricevilo. Telefono, kiu ŝajne uzas unu eliron, diras nenion pri tio, kien iras la trafiko de la televidilo.
Ĝuste tiu divido igas la paneon stranga. La tunelo ŝanĝis la enkursigan tabelon de la telefono kaj ne ŝanĝis tiun de la televidilo, do simptomo aperanta sur unu flanko de la paro devas esti spurata sur tiu flanko. Spuri la malĝustan aparaton estas la kutima kialo, ke ripeto ŝajnas fari nenion.
Kial malkovro rompiĝas unue
Malkovro kutime iras per loka multicast. mDNS sendas al 224.0.0.251 sur UDP-pordo 5353, kaj SSDP sendas al 239.255.255.250 sur UDP-pordo 1900. Ambaŭ estas laŭteme limigitaj al unu ligilo, tial enkursigilo ne plusendas ilin inter segmentoj sen helpo de ripetilo aŭ prokura servilo. Enkursigita VPN ne etendas multicast-grupon, kaj politika vojo ne povas igi grupon, kiu neniam forlasis la ligilon, aperi sur alia.
Do la unua paneo havas nenion komunan kun ĉifrado. La multicast de la telefono forlasas la interfacon, sur kiun ĝi estis sendita, la ricevilo estas en segmento, kiu neniam vidas ĝin, kaj la listo de aparatoj revenas malplena. Malplena listo ne estas pruvo, ke la televidilo perdis aliron al la interreto.
Izolado produktas identan simptomon sen ajna VPN. Gasta retoj kaj klienta izolado ĉe alirpunktoj intence malhelpas aparatojn paroli unu kun la alia, kaj ŝalti enkursigilan VPN sur izolita segmento ŝanĝas nenion pri tio. Kontrolu la izoladan agordon antaŭ ol kontroli la tunelon. Ĝi estas la pli malmultekosta respondo kaj la pli ofta.
La aranĝo de segmentoj estas la alia duono. Dua enkursigilo, mesh-nodo en alia reĝimo aŭ kabla segmento malantaŭ alia NAT ĉiuj metas la ricevilon tie, kien la malkovra trafiko de la telefono ne atingas.
Kial defaŭlta politiko povas engluti lokan peton
Enkursigilo, kiu direktas la tutan trafikon en tunelon, instalas defaŭltan vojon sur la tunela interfaco. Se la prefikso de la loka reto ne estas esceptita de tiu politiko, pako adresita al aparato du metrojn for nun kongruas kun la defaŭlto, kaj la enkursigilo sendas la regan peton en la tunelon anstataŭ al la komutilo.
| Stage | What carries it | How a router VPN interferes |
|---|---|---|
| Discovery | Link-local multicast on a single segment | Not extended across segments, and not repaired by a route |
| Control connection | Unicast to the receiver address on the LAN | A policy default can capture the LAN destination and tunnel it |
| Media fetch | The receiver's own connection | Unaffected by the phone's route, but affected by the TV's own policy |
| Account authorization | Tokens held by the application | Can fail for reasons unrelated to any route |
La ordo de la reguloj decidas la rezulton. Politika enkursigado taksas regulojn laŭ prioritata ordo, do escepto por la loka prefikso devas aperi antaŭ la regulo, kiu elektas la tunelan tabelon. Aldoni la escepton post la tunela regulo havas neniun efikon, tial ŝajne ĝusta agordo ankoraŭ povas sendi lokan trafikon al fora eliro.
La riparo estas mallarĝa: permesu la koncernajn lokajn celojn, kiujn la ĵetada fluo bezonas, kaj lasu la reston de la izolado trankvila. Forigi klientan izoladon kiel unuan paŝon forigas la simptomon, sed forĵetas regilon, kiun la reto estis destinita havi.
Rapida kontrolo en la telefono decidas, kiun el la du paneoj vi havas. Se la vojo al la ricevilo montras al la tunelo, la politiko estas la problemo. Se ĝi montras al la loka reto kaj malkovro ankoraŭ fiaskas, multicast aŭ izolado estas la problemo, kaj neniu voja ŝanĝo helpos.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTestu la paŝon, kiu ŝanĝiĝis, ne la landon
Notitaj observoj valoras pli ol ripetitaj eksperimentoj. Notu, ĉu la ricevilo aperas en la aparato-listo, ĉu rega peto atingas ĝin, kaj ĉu ludado komenciĝas post elekti fluon. Ĉiu respondo forigas unu paŝon el la suspekto.
Poste testu ĉiun paŝon rekte anstataŭ ŝanĝi elirajn lokojn. Ŝanĝi landon de VPN testas la vojon de la amaskomunikiloj kaj lasas la malkovran kaj regan paŝojn netuŝitaj, do ĝi povas hazarde ŝajni helpi, sen instrui al vi ion.
Ĉe la ricevila flanko kontrolu ĝian propran vojon kaj ĝian kontan staton. Televidilo, kiu elŝutas amaskomunikilojn tra alia eliro ol la telefono, estas normala dizajno, kaj paneo tie estas demando pri la reta politiko de la ricevilo, ne pri la tunelo de la telefono.
Skribu la rezulton kiel unu frazon pri tio, kiu paŝo rompiĝis kaj kio ŝanĝis ĝin. Tiu frazo valoras pli ol semajno da lando-ŝanĝado, kaj ĝi postvivas la sekvan firmvaran ĝisdatigon.
Ĵetado estas bona testa kazo por ĝenerala regulo pri tuneloj. Kiam oni aldonas unu al reto, la unua demando estas kiuj celoj neniam devintus eniri ĝin. La dua estas, kiujn el ili la politiko tamen silente akceptis.