Transmiterea pe VPN: descoperire, control sau flux?
Un receptor lipsă, o sesiune refuzată și un flux care se blochează eșuează în locuri diferite. Numește etapa înainte de a schimba politica VPN a telefonului sau rețeaua.
Transmiterea se strică în trei locuri care arată identic de pe canapea. Telefonul poate să nu vadă niciodată receptorul, receptorul poate să apară și apoi să refuze sesiunea, sau sesiunea poate porni și se blochează un minut mai târziu. Un tunel pe telefon schimbă fiecare dintre aceste căi altfel, iar pentru una dintre ele nu schimbă nimic. Numește mai întâi etapa care eșuează, apoi decide dacă schimbarea politicii este chiar pârghia potrivită.
Numește etapa care eșuează înainte de a schimba politica
Urmărește ce face telefonul imediat după ce atingi pictograma de transmitere. O listă goală este un rezultat al descoperirii, o atingere care raportează o eroare este un rezultat al controlului, iar o sesiune care pornește înainte de a se bloca este un rezultat al redării. Acestea trei au proprietari diferiți, iar de obicei doar primele două implică setările tunelului telefonului.
| Stage | What the phone shows | Evidence that separates it |
|---|---|---|
| Discovery | No receiver in the list | Another device on the same segment sees the receiver |
| Control | Receiver listed, session refused | Port answer versus permission prompt |
| Playback | Session starts, then stalls | The receiver's own link, not the phone's |
Notează etapa înainte de a schimba ceva. O corecție aplicată la etapa greșită face următorul test ilizibil, iar cea mai mare parte a folclorului despre transmitere vine exact din această confuzie.
Descoperirea este trafic local, iar un tunel o ascunde
Receptoarele se anunță prin anunțuri locale, iar telefonul le găsește prin interogări pe același link, așa că orice scoate telefonul de pe acel link scoate receptorul din listă. Un tunel care rutează tot traficul departe de LAN poate ascunde aceste schimburi, iar o permisiune de rețea locală la nivel de aplicație le poate bloca chiar și atunci când ruta există. Wi-Fi pentru oaspeți cu izolare a clienților produce aceeași listă goală fără niciun VPN. Dovedește că cele două dispozitive împart un segment înainte de a da vina pe tunel.
avahi-browse -at | grep -i -E 'chromecast|googlecast'
dig +short @224.0.0.251 -p 5353 _googlecast._tcp.local PTRPrima comandă listează ce se anunță pe segmentul mașinii ajutătoare, iar a doua întreabă direct grupul DNS multicast. Un receptor absent din ambele nu va apărea nici într-o aplicație de telefon, oricare ar fi starea tunelului. Dacă receptorul este vizibil de pe un dispozitiv cu tunelul oprit și invizibil de pe unul cu tunelul pornit, ai găsit etapa și cauza împreună.
O excepție LAN ține tunelul pornit
Mulți clienți oferă o excepție de rețea locală care lasă tunelul activ permițând adrese locale. Folosește acea setare documentată în loc să oprești kill switch-ul sau tot firewall-ul, pentru că acelea schimbă mult mai mult decât are nevoie transmiterea. Dacă rețeaua separă intenționat dispozitivele inteligente, cere proprietarului traficul specific de descoperire, control și retur, nu acces plat.
nc -vz 192.168.1.50 8009Un test de control către receptor separă permisiunea de accesibilitate: un port care răspunde înseamnă că traseul există, iar un refuz înseamnă că telefonului i s-a permis să descopere dispozitivul și tot nu poate vorbi cu el. Porturile 8008 și 8009 sunt porturile obișnuite de transmitere, iar o aplicație poate folosi altele, așa că tratează un singur port refuzat ca indiciu, nu ca verdict. Excepția și permisiunea aplicației rămân independente, fiindcă acordarea accesului local nu creează o rută, iar adăugarea unei rute nu acordă permisiune. Un kill switch poate și să elimine traficul local după o reconectare, de aceea descoperirea trebuie retestată când tunelul revine.
Redarea poate să nu folosească conexiunea telefonului
Într-o sesiune dirijată de aplicație, telefonul îi dă receptorului o adresă media, iar receptorul o aduce prin propria conexiune, așa că schimbarea adresei publice a telefonului nu face nimic pentru flux. Un titlu limitat de cont poate eșua în continuare din motive proprii, iar cerințele de transmitere Google acoperă compatibilitatea aplicației și a dispozitivului, nu traseul de rețea. Rutarea televizorului însuși printr-un tunel este o configurație separată, cu propriile întrebări de politică.
Două indicii despart modurile. O transmitere care rezistă când ecranul telefonului se blochează este dirijată de aplicație, fiindcă receptorul aduce singur; o oglindire care se oprește când ecranul expeditorului se blochează este un flux continuu de la telefon. Când descoperirea și controlul reușesc, dar redarea se blochează, uită-te la legătura Wi-Fi a receptorului și la traseul lui spre internet, fiindcă un test de viteză pe telefon descrie telefonul, nu televizorul.
Anulează excepția și retestează
Fiecare schimbare temporară are nevoie de o cale de întoarcere, iar ordinea contează. Elimină excepția LAN, reconectează tunelul ca să-și reaplice clientul politica, apoi repetă pasul de descoperire și notează dacă receptorul dispare din nou. Secvența îți spune dacă excepția făcea treaba sau dacă s-a schimbat altceva între timp.
# 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'Verifică apoi cele trei etape separat, fiindcă o reușită la una nu spune nimic despre celelalte. Apoi verifică dacă aplicațiile telefonului fără legătură urmează în continuare traseul dorit, fiindcă o excepție locală care a devenit în liniște o ocolire completă este un rezultat mai rău decât o transmitere care cere o atingere în plus.