Smart-TV på VPN: hvorfor cast og DNS bryder sammen hver for sig
Rut TV'ets trafik på routeren, og behandl derefter vælgeren, resolveren, IPv6 og cast-stien som fire separate kontroller.
Dit tv viser det udenlandske katalog, og telefonens cast-knap viser det ikke længere. Begge klager begynder med én sætning, der navngiver fire indstillinger på fire routersider. Ret udgangen, og opdagelsen bryder sammen; ret opdagelsen, og den næste lease giver udgangen til en anden enhed. Rækkefølgen nedenfor går fra vælgeren ud til cast-stien.
Hvor hver af de fire beslutninger bor
Skriv de fire ned, før du åbner en menu, fordi hver især bor på en anden side og fejler et andet sted. Vælgeren bestemmer, hvilken klient tunnelen gælder for, resolveren bestemmer, hvor navne besvares, adressefamilien bestemmer, om IPv6 overhovedet er dækket, og den lokale sti bestemmer, om telefonen og tv'et stadig kan se hinanden. En ændring i én ser komplet ud fra den side, du står på. Skaden fra de tre andre dukker op senere, i en anden menu, som en anden klage.
Firmwaremenuer er forskellige, men de fire steder er sjældent. Vælgeren er en statisk mappning på DHCP-serveren plus en firewallregel, der matcher den. Resolveren sidder ved DNS-tjenesten, hvor en forwarder-post eller en liste over upstream-servere bestemmer, hvilke navne routeren besvarer, og hvor forespørgslerne forlader. Familieindstillingen hører til selve interfacet, hvor IPv4 og IPv6 konfigureres hver for sig, og en politik kun kan dække den første. Den lokale sti er en accesspunkt-switch, enten klientisolering eller et gæstenetværk med sin egen firewall.
Lad vælgeren overleve leaseaftalen
Både en politik per enhed og et dedikeret segment virker, og det bedre valg er det, som firmwaren kan vedligeholde, uden at en anden person skal huske det. Fælden er en regel fastlåst til en adresse, som DHCP-serveren uddelte efter sin egen tidsplan: den virker, indtil leaseaftalen flytter sig, og sender derefter en laptop gennem et andet land af grunde, som dens ejer ikke kan se. Vedholdenhed, ikke pænhed, er den egenskab, der er værd at optimere.
| Rule names the TV by | After the next lease | What it costs |
|---|---|---|
| whatever address it has now | may point at another client | silent misrouting weeks later |
| a reserved address | holds, if the reservation ships with it | one more entry to keep in step |
| a hardware address | holds, unless the device rotates it | privacy features can break it |
| a whole segment | holds for every device on it | neighbours inherit the exit |
Send reservationen og reglen ud som én ændring, fordi en regel, der overlever sin reservation, er en regel rettet mod en andens hardware. En regel for et helt segment er den mest holdbare og den groveste vælger, da hver enhed bag det interface arver udgangen, uanset om den havde brug for den. Uanset hvilken vælger du vælger, kommer dækningsspørgsmålet derefter: en politik kun for IPv4 er en halv beslutning, og den udækkede familie er den, der forsvinder ubemærket.
Find ud af, hvilken resolver tv'et virkelig bruger
Åbn tv'ets egne netværksindstillinger, før du rører routeren, fordi enheden afgør denne diskussion. Et DNS-felt sat til manuel bliver ved med at bruge den server, uanset hvad DHCP tilbyder, og en set-top-boks, der én gang er konfigureret til en anden region, kan stadig pege på en adresse, der ikke længere svarer. Hvis feltet er automatisk, bestemmer routerens DHCP-indstilling, og routerens egen resolver bliver det næste spørgsmål. Under alle omstændigheder er svaret på enhedens skærm, ikke i firmwaremanualen.
På routersiden er den forskel, der betyder noget, mellem navne, som routeren selv besvarer, og navne, som den videresender, fordi disse to stier kan forlade gennem forskellige interfaces. Et opslag, der løses korrekt, siger derfor intet om, hvor en medieanmodning går hen, og på en Linux-gateway besvarer politiktavlen plus et enkelt ruteopslag begge spørgsmål uden at fange noget på tv'et:
ip rule show
ip route get 203.0.113.10
Læs den første kommando for den regel, der markerer tv'ets trafik, og den anden for det interface, som en pakke til eksempeladressen faktisk ville bruge. Når de to er uenige, er det ikke resolverens skyld; det er politikken. Ændr én ting, og kør derefter parret igen, fordi en regelliste er ordensfølsom, og en ny post kan skygge for den regel, der bar trafikken. Destinationen er reserveret til dokumentation, så et indsat output læses som et eksempel.
Cast bryder sammen ved opdagelsen, ikke ved streamen
Cast er mindst tre samtaler, og kun én af dem bærer video. Telefonen opdager tv'et via multicast eller broadcast på det lokale segment, åbner en kontrolkanal for at sige, hvad der skal afspilles, og derefter henter tv'et enten streamen selv eller modtager den videresendt fra telefonen. Opdagelse krydser aldrig en router, der ikke videresender den trafik, og det er sådan et tv kan routes præcis som tilsigtet og alligevel aldrig dukke op på cast-listen.
Gæstenetværk og klientisolering er den sædvanlige årsag, og begge gør præcis, hvad de blev konfigureret til. At slå isolering fra på hele det trådløse netværk, så én enhed dukker op igen, er den sædvanlige overkorrektion, og den genåbner hver telefon-til-telefon-sti, som indstillingen fandtes for at lukke. Der findes smallere svar: en pass-regel for opdagelses- og kontroltrafik mellem to adresser, et separat SSID til tv'erne eller én dokumenteret undtagelse på gæstenetværket.
Test cast, mens isolationsreglen stadig er på plads, og tilføj derefter kun opdagelsesundtagelsen og test igen. Hvis det andet forsøg finder tv'et, er undtagelsen løsningen, og resten af segmentet kan blive, som det var.
Stop tunnelen, og se, hvilken vej den fejler
Den sidste kontrol er den, de fleste opsætninger springer over: tag tunnelen ned, og se, om tv'et stopper, eller stille forlader via den lokale forbindelse. En politik, der udtrykker en præference, fejler åbent, og den fejl er let at overse, fordi afspilningen fortsætter, mens udgangen flytter tilbage til ISP'en. En kill-switch-regel fejler lukket i stedet, og tv'et rapporterer intet, før tunnelen vender tilbage. Ingen af de to adfærde er forkert; det er forkert ikke at vide, hvilken du konfigurerede.
Tjek fire ting igen efter enhver ændring, i denne rækkefølge. Vælgeren matcher stadig enheden efter den næste lease eller genstart. Resolveren svarer på den sti, politikken tilsigter, i stedet for fra en server, enheden huskede. Adressefamilien i politikken dækker hver familie, som tv'et og adgangsnetværket faktisk bruger. Cast finder stadig tv'et fra den telefon, der virkelig skal bruges, ikke fra en testtelefon på samme SSID.
Hold de fire linjer ved siden af routerkonfigurationen i stedet for i en chattråd: hvad reglen matcher, hvilken resolver tv'et spørger, hvilken familie der er dækket, og hvilken lokal sti cast har brug for. Den næste person, der åbner firewallen, læser konfigurationen længe før, de læser en sag. Til den tid kan den person være dig.