Smart-TV på VPN: hvorfor cast og DNS bryter sammen hver for seg
Rut TV-ens trafikk på ruteren, og behandle deretter velgeren, resolveren, IPv6 og cast-stien som fire separate kontroller.
TV-en din viser den utenlandske katalogen, og cast-knappen på telefonen viser den ikke lenger. Begge klagene begynner med én setning som navngir fire innstillinger på fire ruterseider. Reparer utgangen og oppdagelsen brytes; reparer oppdagelsen og neste lease gir utgangen til en annen enhet. Rekkefølgen nedenfor går fra velgeren ut til cast-stien.
Hvor hver av de fire beslutningene bor
Skriv ned de fire før du åpner en meny, fordi hver av dem bor på en annen side og feiler på et annet sted. Velgeren bestemmer hvilken klient tunnelen gjelder for, resolveren bestemmer hvor navn besvares, adressefamilien bestemmer om IPv6 i det hele tatt er dekket, og den lokale stien bestemmer om telefonen og TV-en fortsatt ser hverandre. En endring i én ser komplett ut fra siden du står på. Skaden fra de tre andre dukker opp senere, i en annen meny, som en annen klage.
Firmwaremenyer varierer, men de fire stedene sjelden. Velgeren er en statisk mapping på DHCP-serveren pluss en brannmurregel som passer til den. Resolveren sitter ved DNS-tjenesten, der en videresenderoppføring eller en liste over oppstrøms servere bestemmer hvilke navn ruteren svarer på og hvor spørringene går ut. Familieinnstillingen hører til selve grensesnittet, der IPv4 og IPv6 konfigureres separat og en policy bare kan dekke den første. Den lokale stien er en accesspunkt-bryter, enten klientisolering eller et gjestenettverk med sin egen brannmur.
La velgeren overleve leasen
Både en policy per enhet og et dedikert segment fungerer, og det bedre valget er det firmwaren kan vedlikeholde uten at en annen person må huske det. Fellen er en regel festet til en adresse som DHCP-serveren delte ut etter sin egen plan: den virker til leasen flytter seg, og sender deretter en laptop gjennom et annet land av grunner eieren ikke kan se. Vedholdenhet, ikke ryddighet, er egenskapen som er verdt å optimalisere.
| 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 reservasjonen og regelen ut som én endring, fordi en regel som overlever reservasjonen sin, er en regel rettet mot andres maskinvare. En regel for et helt segment er den mest holdbare og groveste velgeren, siden hver enhet bak det grensesnittet arver utgangen, enten den trengte den eller ikke. Uansett hvilken velger du velger, kommer dekningsspørsmålet neste: en policy bare for IPv4 er en halv beslutning, og den udekkede familien er den som forsvinner ubemerket.
Finn ut hvilken resolver TV-en virkelig bruker
Åpne TV-ens egne nettverksinnstillinger før du rører ruteren, fordi enheten avgjør denne diskusjonen. Et DNS-felt satt til manuell fortsetter å bruke den serveren uansett hva DHCP tilbyr, og en set-top-boks som én gang ble konfigurert for en annen region, kan fortsatt peke på en adresse som ikke lenger svarer. Hvis feltet er automatisk, avgjør ruterens DHCP-alternativ, og ruterens egen resolver blir det neste spørsmålet. Uansett er svaret på enhetens skjerm, ikke i firmwarehåndboken.
På ruterseiden er skillet som betyr noe, mellom navn ruteren svarer på selv, og navn den videresender, fordi disse to stiene kan gå ut gjennom forskjellige grensesnitt. Et oppslag som løses riktig, sier derfor ingenting om hvor en medieforespørsel går, og på en Linux-gateway svarer policytabellen pluss ett enkelt ruteoppslag på begge spørsmålene uten å fange noe på TV-en:
ip rule show
ip route get 203.0.113.10Les den første kommandoen for regelen som markerer TV-ens trafikk, og den andre for grensesnittet en pakke til eksempeladressen faktisk ville brukt. Når de to er uenige, er det ikke resolverens skyld; det er policyen. Endre én ting, og kjør deretter paret igjen, fordi en regelliste er ordensfølsom og en ny oppføring kan skygge for regelen som bar trafikken. Destinasjonen er reservert for dokumentasjon, så en limt inn utskrift leses som et eksempel.
Cast bryter sammen ved oppdagelsen, ikke ved strømmen
Cast er minst tre samtaler, og bare én av dem bærer video. Telefonen oppdager TV-en via multicast eller broadcast på det lokale segmentet, åpner en kontrollkanal for å si hva som skal spilles av, og deretter henter TV-en strømmen selv eller mottar den videresendt fra telefonen. Oppdagelse krysser aldri en ruter som ikke videresender den trafikken, og det er slik en TV kan rutes nøyaktig som tiltenkt og likevel aldri dukke opp i cast-listen.
Gjestenettverk og klientisolering er den vanlige årsaken, og begge gjør nøyaktig det de ble konfigurert til. Å slå av isolering i hele det trådløse nettverket slik at én enhet dukker opp igjen, er den vanlige overkorrigeringen, og den åpner igjen hver telefon-til-telefon-sti som innstillingen fantes for å lukke. Det finnes smalere svar: en pass-regel for oppdagelses- og kontrolltrafikk mellom to adresser, en egen SSID for TV-ene, eller ett dokumentert unntak på gjestenettverket.
Test cast mens isoleringsregelen fortsatt er på plass, legg deretter bare til oppdagelsesunntaket og test igjen. Hvis det andre forsøket finner TV-en, er unntaket løsningen, og resten av segmentet kan bli som det var.
Stopp tunnelen og se hvilken vei den feiler
Den siste kontrollen er den de fleste oppsett hopper over: ta tunnelen ned og se om TV-en stopper eller stille forlater via den lokale forbindelsen. En policy som uttrykker en preferanse, feiler åpent, og den feilen er lett å overse fordi avspillingen fortsetter mens utgangen flytter tilbake til ISP-en. En kill-switch-regel feiler lukket i stedet, og TV-en rapporterer ingenting før tunnelen kommer tilbake. Ingen av de to oppførslene er feil; det er feil å ikke vite hvilken du konfigurerte.
Sjekk fire ting på nytt etter enhver endring, i denne rekkefølgen. Velgeren passer fortsatt til enheten etter neste lease eller omstart. Resolveren svarer på stien policyen tar sikte på, ikke fra en server enheten husket. Adressefamilien i policyen dekker hver familie TV-en og aksessnettet faktisk bruker. Cast finner fortsatt TV-en fra telefonen som virkelig skal brukes, ikke fra en testtelefon på samme SSID.
Hold de fire linjene ved siden av ruterens konfigurasjon i stedet for i en chat-tråd: hva regelen matcher, hvilken resolver TV-en spør, hvilken familie som er dekket, og hvilken lokal sti cast trenger. Den neste personen som åpner brannmuren, leser konfigurasjonen lenge før de leser en sak. Innen den tid kan den personen være deg.