Smart-TV på VPN: varför cast och DNS går sönder var för sig

Din tv visar den utländska katalogen, och telefonens cast-knapp listar den inte längre. Båda klagomålen börjar med en mening som namnger fyra inställningar på fyra routersidor. Reparera utgången och upptäckten går sönder; reparera upptäckten och nästa lease ger utgången till en annan enhet. Ordningen nedan går från väljaren ut till cast-vägen.

Var var och en av de fyra besluten bor

Skriv ner alla fyra innan du öppnar en meny, eftersom var och en bor på en annan sida och misslyckas på ett annat ställe. Väljaren avgör vilken klient tunneln gäller, resolvern avgör var namn besvaras, adressfamiljen avgör om IPv6 alls täcks, och den lokala vägen avgör om telefonen och tv:n fortfarande ser varandra. En ändring i en ser komplett ut från sidan du står på. Skadan från de andra tre dyker upp senare, i en annan meny, som ett annat klagomål.

Firmwaremenyer skiljer sig, men de fyra platserna sällan. Väljaren är en statisk mappning på DHCP-servern plus en brandväggsregel som matchar den. Resolvern sitter vid DNS-tjänsten, där en vidarebefordrarpost eller en lista över uppströms servrar avgör vilka namn routern svarar på och varifrån frågorna går ut. Familjeinställningen hör till själva gränssnittet, där IPv4 och IPv6 konfigureras separat och en policy bara kan täcka den första. Den lokala vägen är en accesspunktsbrytare, antingen klientisolering eller ett gästnätverk med egen brandvägg.

Låt väljaren överleva leasen

Både en policy per enhet och ett dedikerat segment fungerar, och det bättre valet är det firmware kan underhålla utan att en andra person måste komma ihåg det. Fällan är en regel låst till en adress som DHCP-servern delade ut enligt sitt eget schema: den fungerar tills leasen flyttar sig och routar sedan en laptop genom ett annat land av skäl som ägaren inte kan se. Uthållighet, inte ordning, är egenskapen som är värd att optimera.

Skicka reservationen och regeln som en enda ändring, för en regel som överlever sin reservation är en regel riktad mot någon annans hårdvara. En regel för ett helt segment är den mest hållbara och grövsta väljaren, eftersom varje enhet bakom det gränssnittet ärver utgången, oavsett om den behövde den eller inte. Vilken väljare du än väljer kommer täckningsfrågan härnäst: en policy bara för IPv4 är ett halvt beslut, och den otäckta familjen är den som lämnar obemärkt.

Ta reda på vilken resolver tv:n verkligen använder

Öppna tv:ns egna nätverksinställningar innan du rör routern, eftersom enheten avgör den här diskussionen. Ett DNS-fält inställt på manuellt fortsätter använda den servern vad DHCP än erbjuder, och en set-top-box som en gång konfigurerats för en annan region kan fortfarande peka på en adress som inte längre svarar. Om fältet är automatiskt avgör routerns DHCP-alternativ, och routerns egen resolver blir nästa fråga. Hur som helst står svaret på enhetens skärm, inte i firmwarehandboken.

På routersidan är skillnaden som spelar roll den mellan namn som routern svarar på själv och namn som den vidarebefordrar, eftersom dessa två vägar kan gå ut genom olika gränssnitt. En uppslagning som löses korrekt säger därför ingenting om vart en medieförfrågan tar vägen, och på en Linux-gateway svarar policytabellen plus en enda ruttuppslagning på båda frågorna utan att fånga något på tv:n:

ip rule show
ip route get 203.0.113.10

Läs det första kommandot för regeln som markerar tv:ns trafik och det andra för gränssnittet som ett paket till exempeladressen faktiskt skulle använda. När de två är oense är det inte resolverns fel; det är policyns. Ändra en sak och kör sedan paret igen, för en regellista är ordningskänslig och en ny post kan skugga regeln som bar trafiken. Destinationen är reserverad för dokumentation, så en inklistrad utskrift läses som ett exempel.

Cast går sönder vid upptäckten, inte vid strömmen

Cast är minst tre samtal och bara ett av dem bär video. Telefonen upptäcker tv:n via multicast eller broadcast i det lokala segmentet, öppnar en kontrollkanal för att säga vad som ska spelas, och sedan hämtar tv:n strömmen själv eller tar emot den vidarebefordrad från telefonen. Upptäckt korsar aldrig en router som inte vidarebefordrar den trafiken, och det är så en tv kan routas exakt som avsett och ändå aldrig dyka upp i cast-listan.

Gästnätverk och klientisolering är den vanliga orsaken, och båda gör exakt det de konfigurerades för. Att stänga av isolering i hela det trådlösa nätet så att en enhet dyker upp igen är den vanliga överkorrigeringen, och den öppnar igen varje telefon-till-telefon-väg som inställningen fanns för att stänga. Det finns snävare svar: en pass-regel för upptäckts- och kontrolltrafik mellan två adresser, ett eget SSID för tv-apparaterna, eller ett dokumenterat undantag på gästnätverket.

Testa cast medan isoleringsregeln fortfarande är på plats, lägg sedan bara till upptäcktsundantaget och testa igen. Om det andra försöket hittar tv:n är undantaget lösningen och resten av segmentet kan förbli som det var.

Stoppa tunneln och se åt vilket håll den misslyckas

Den sista kontrollen är den som de flesta installationer hoppar över: ta ner tunneln och se om tv:n stannar eller tyst lämnar via den lokala anslutningen. En policy som uttrycker en preferens misslyckas öppet, och det felet är lätt att missa eftersom uppspelningen fortsätter medan utgången flyttar tillbaka till ISP:n. En kill-switch-regel misslyckas i stället stängt, och tv:n rapporterar ingenting förrän tunneln återvänder. Inget av de två beteendena är fel; att inte veta vilket du konfigurerade är det.

Kontrollera fyra saker igen efter varje ändring, i den här ordningen. Väljaren matchar fortfarande enheten efter nästa lease eller omstart. Resolvern svarar på den väg policyn avser, inte från en server enheten kom ihåg. Adressfamiljen i policyn täcker varje familj som tv:n och åtkomstnätet faktiskt använder. Cast hittar fortfarande tv:n från telefonen som verkligen kommer att användas, inte från en testtelefon på samma SSID.

Håll de fyra raderna vid sidan av routerkonfigurationen i stället för i en chattråd: vad regeln matchar, vilken resolver tv:n frågar, vilken familj som täcks och vilken lokal väg cast behöver. Nästa person som öppnar brandväggen läser konfigurationen långt innan hen läser ett ärende. Till dess kan den personen vara du.