De ce difuzarea încetează să funcționeze după activarea VPN-ului pe router
Descoperirea merge prin multicast link-local, iar televizorul își descarcă singur media. O regulă implicită a politicii poate prinde cererea LAN și o poate trimite în tunel.
Difuzarea funcționa înainte de activarea VPN-ului pe router și eșuează imediat după, în timp ce navigarea obișnuită pe telefon încă funcționează. Cele două fapte sunt consecvente, pentru că difuzarea nu este o singură conexiune. Telefonul descoperă și controlează receptorul prin rețeaua locală, iar apoi receptorul descarcă media prin propria conexiune.
Două căi care eșuează diferit
Calea de control este locală. Telefonul găsește un receptor întrebând rețeaua locală, apoi deschide o conexiune de control către adresa pe care a aflat-o. Dacă receptorul nu apare niciodată în listă, pasul de descoperire a eșuat înainte de a se fi cerut vreo media.
Calea media nu este neapărat locală. Multe receptoare descarcă fluxul singure, prin propria conexiune și cu propriile credențiale, așa că ruta telefonului nu descrie ruta receptorului. Un telefon care pare să folosească o singură ieșire nu spune nimic despre unde ajunge traficul televizorului.
Această separare este motivul pentru care defecțiunea arată ciudat. Tunelul a schimbat tabela de rutare a telefonului și nu a schimbat-o pe cea a televizorului, așa că un simptom care apare pe o parte a perechii trebuie urmărit pe acea parte. Investigarea dispozitivului greșit este motivul obișnuit pentru care o remediere pare să nu facă nimic.
De ce descoperirea se strică prima
Descoperirea merge de obicei prin multicast link-local. mDNS trimite către 224.0.0.251 pe portul UDP 5353, iar SSDP trimite către 239.255.255.250 pe portul UDP 1900. Ambele sunt limitate la o singură legătură prin construcție, de aceea routerul nu le transmite mai departe între segmente fără ajutorul unui repetor sau al unui proxy. Un VPN rutat nu extinde un grup multicast, iar o rută de politică nu poate face un grup care nu a părăsit niciodată legătura să apară pe alta.
Deci prima defecțiune nu are nicio legătură cu criptarea. Multicast-ul telefonului părăsește interfața pe care a fost trimis, receptorul este într-un segment care nu îl vede niciodată, iar lista de dispozitive revine goală. O listă goală nu este dovada că televizorul a pierdut accesul la internet.
Izolarea produce un simptom identic fără niciun VPN. Rețelele de oaspeți și izolarea clienților la punctul de acces opresc intenționat dispozitivele să comunice între ele, iar activarea unui VPN pe router peste un segment izolat nu schimbă nimic în privința asta. Verificați setarea de izolare înainte de a verifica tunelul. Este răspunsul mai ieftin și mai frecvent.
Aspectul segmentelor este cealaltă jumătate. Un al doilea router, un nod mesh în alt mod sau un segment cu cablu în spatele unui alt NAT pun receptorul acolo unde traficul de descoperire al telefonului nu ajunge.
De ce o regulă implicită a politicii poate înghiți o cerere locală
Un router care trimite tot traficul într-un tunel instalează o rută implicită pe interfața tunelului. Dacă prefixul LAN nu este exclus din acea politică, un pachet adresat unui dispozitiv aflat la doi metri corespunde acum rutei implicite, iar routerul trimite cererea de control în tunel în loc de switch.
| 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 |
Ordinea regulilor decide rezultatul. Rutarea pe politică evaluează regulile în ordinea priorității, deci o excepție pentru prefixul local trebuie să stea înaintea regulii care selectează tabela tunelului. Adăugarea excepției după regula tunelului nu are efect, de aceea o configurație care pare corectă poate trimite în continuare trafic LAN către o ieșire îndepărtată.
Remedierea este îngustă: permiteți destinațiile locale concrete de care are nevoie fluxul de difuzare și lăsați restul izolării în pace. Scoaterea izolării clienților ca prim pas vindecă simptomul, dar aruncă un control pe care rețeaua a fost proiectată să îl aibă.
O verificare rapidă pe telefon stabilește care dintre cele două defecțiuni este. Dacă ruta către receptor arată spre tunel, problema este politica. Dacă arată spre LAN și descoperirea tot eșuează, problema este multicast-ul sau izolarea, iar nicio schimbare de rută nu va ajuta.
ip route get 192.168.1.50
ip rule show
avahi-browse -rt _googlecast._tcpTestați pasul care s-a schimbat, nu țara
Observațiile notate bat experimentele repetate. Notați dacă receptorul apare în lista de dispozitive, dacă o cerere de control ajunge la el și dacă redarea începe după ce se alege un flux. Fiecare răspuns scoate un pas din suspiciune.
Apoi testați fiecare pas direct, în loc să schimbați locațiile de ieșire. Schimbarea țării VPN testează calea media și lasă pașii de descoperire și control neatinși, așa că poate părea că ajută din întâmplare fără să vă învețe nimic.
Pe partea receptorului, verificați propria rută și starea propriului cont. Un televizor care descarcă media printr-o altă ieșire decât telefonul este un proiect normal, iar o defecțiune acolo este o întrebare despre politica de rețea a receptorului, nu despre tunelul telefonului.
Notați rezultatul într-o singură propoziție despre care pas s-a stricat și ce l-a schimbat. Propoziția aceea valorează mai mult decât o săptămână de schimbat țări și supraviețuiește următoarei actualizări de firmware.
Difuzarea este un caz de test bun pentru o regulă generală despre tuneluri. Când se adaugă unul într-o rețea, prima întrebare este care destinații nu ar fi trebuit să intre niciodată în el. A doua este pe care dintre ele le-a acceptat totuși politica în tăcere.