Elsendo haltas ĉe VPN: malkovro, regado aŭ fluo?

La elsendo rompiĝas en tri lokoj, kiuj de la sofo aspektas samaj. La telefono eble neniam vidos la ricevilon, la ricevilo eble aperos kaj poste rifuzos la seanchon, aŭ la seanco eble komenciĝos kaj ŝanceliĝos minuton poste. Tunelo sur la telefono ŝanĝas ĉiun el tiuj vojoj malsame, kaj por unu el ili ĝi ŝanĝas nenion. Unue nomu la fiaskan etapon, poste decidu ĉu ŝanĝo de politiko eĉ estas la ĝusta levilo.

Nomu la fiaskan etapon antaŭ ol ŝanĝi la politikon

Rigardu, kion la telefono faras tuj post kiam vi tuŝas la elsendan ikonon. Malplena listo estas rezulto de malkovro, tuŝo raportanta fiaskon estas rezulto de regado, kaj seanco komenciĝanta antaŭ ol ŝanceliĝi estas rezulto de ludado. Tiuj tri havas malsamajn posedantojn, kaj kutime nur la du unuaj koncernas la tunelajn agordojn de la telefono.

Skribu la etapon antaŭ ol ŝanĝi ion ajn. Riparo aplikata al la malĝusta etapo faras la sekvan teston nelegebla, kaj plej multaj elsendaj mitoj venas ĝuste el tiu konfuzo.

Malkovro estas loka trafiko, kaj tunelo kaŝas ĝin

Riceviloj anoncas sin per lokaj anoncoj kaj la telefono trovas ilin per demandoj sur la sama ligo, do io ajn, kio forigas la telefonon de tiu ligo, forigas la ricevilon de la listo. Tunelo, kiu direktas la tutan trafikon for de la LAN, povas kaŝi tiujn interŝanĝojn, kaj loka-reta permeso je aplika nivelo povas bloki ilin eĉ kiam la vojo ekzistas. Gasta Wi-Fi kun klienta izolado produktas la saman malplenan liston tute sen VPN. Pruvu, ke la du aparatoj kunhavas segmenton, antaŭ ol kulpigi la tunelon.

avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTR

La unua komando listigas, kio anoncas sin en la segmento de la helpmaŝino, kaj la dua demandas rekte la multdisvastigan DNS-grupon. Ricevilo mankanta en ambaŭ ankaŭ ne aperos en telefono-aplikaĵo, kia ajn estas la tunela stato de la telefono. Se la ricevilo videblas de aparato kun malŝaltita tunelo kaj nevideblas de aparato kun ŝaltita, vi trovis la etapon kaj la kaŭzon kune.

LAN-escepto tenas la tunelon aktiva

Multaj klientoj proponas lokretan escepton, kiu lasas la tunelon aktiva dum permesas lokajn adresojn. Uzu tiun dokumentitan agordon anstataŭ malŝalti la mortigilon aŭ la tutan fajroŝirmilon, ĉar tiuj ŝanĝas multe pli ol la elsendo bezonas. Se la reto intence apartigas inteligentajn aparatojn, petu de la posedanto la specifan malkovran, regadan kaj revenan trafikon anstataŭ plata aliro.

nc -vz 192.168.1.50 8009

Regada testo kontraŭ la ricevilo apartigas permeson de atingeblo: pordo, kiu respondas, signifas ke la vojo ekzistas, dum rifuzo signifas ke la telefono rajtis malkovri la aparaton kaj tamen ne povas paroli kun ĝi. Pordoj 8008 kaj 8009 estas la kutimaj elsendaj pordoj, kaj aplikaĵo povas uzi aliajn, do traktu unu rifuzitan pordon kiel indikon, ne kiel verdikton. La escepto kaj la aplika permeso restas sendependaj, ĉar loka aliro ne kreas vojon kaj aldoni vojon ne donas permeson. Mortigilo ankaŭ povas faligi lokan trafikon post rekonekto, tial la malkovro devas esti retestata tuj kiam la tunelo revenas.

Ludado eble ne uzas la konekton de la telefono

En aplikaĵ-direktita seanco la telefono donas al la ricevilo amaskomunikilan adreson kaj la ricevilo elŝutas ĝin per sia propra konekto, do ŝanĝi la publikan adreson de la telefono faras nenion por la fluo. Titolo limigita per konto tamen povas fiaski pro propraj kialoj, kaj la elsendaj postuloj de Google kovras aplikaĵan kaj aparatan kongruecon, ne la retan vojon. Direkti la televidilon mem tra tunelo estas aparta agordo kun propraj politikaj demandoj.

Du indicoj distingas la reĝimojn. Elsendo, kiu postvivas ŝlosadon de la telefona ekrano, estas aplikaĵ-direktita, ĉar la ricevilo elŝutas mem; spegulado, kiu haltas kiam la ekrano de la sendanto ŝlosiĝas, estas kontinua fluo el la telefono. Kiam malkovro kaj regado sukcesas sed ludado ŝanceliĝas, rigardu anstataŭe la Wi-Fi-ligon de la ricevilo kaj ĝian interretan vojon, ĉar rapidotesto sur la telefono priskribas la telefonon, ne la televidilon.

Malfaru la escepton kaj retestu

Ĉiu provizora ŝanĝo bezonas revenan vojon, kaj la ordo gravas. Forigu la LAN-escepton, rekonektu la tunelon por ke la kliento reaplikigu sian politikon, poste ripetu la malkovran paŝon kaj notu ĉu la ricevilo denove malaperas. Tiu sinsekvo diras al vi ĉu la escepto faris la laboron aŭ ĉu io alia ŝanĝiĝis intertempe.

# after removing the LAN exception, reconnect and confirm the tunnel is up
resolvectl status | grep -E 'DNS Servers|Default Route|Protocols'
avahi-browse -at | grep -i -E 'chromecast|googlecast'

Poste kontrolu la tri etapojn aparte, ĉar sukceso ĉe unu diras nenion pri la aliaj. Poste kontrolu, ke nerilataj telefonaj aplikaĵoj ankoraŭ sekvas la celitan vojon, ĉar loka escepto, kiu silente fariĝis kompleta pretervojo, estas pli malbona rezulto ol elsendo, kiu bezonas unu kroman tuŝon.