Smart-TV på VPN: kvifor cast og DNS bryt saman kvar for seg
Rut trafikken til TV-en på rutaren, og handsam deretter veljaren, resolvaren, IPv6 og cast-stien som fire separate kontrollar.
TV-en din viser den utanlandske katalogen, og cast-knappen på telefonen viser han ikkje lenger. Begge klagene byrjar med éi setning som namngir fire innstillingar på fire rutarsider. Reparer utgangen og oppdaginga bryt saman; reparer oppdaginga og neste leige gjev utgangen til ein annan eining. Rekkjefølgja nedanfor går frå veljaren ut til cast-stien.
Kvar kvar av dei fire avgjerdene bur
Skriv ned dei fire før du opnar ein meny, fordi kvar av dei bur på ei anna side og feilar på ein annan stad. Veljaren avgjer kva klient tunnelen gjeld for, resolvaren avgjer kvar namn vert svara på, adressefamilien avgjer om IPv6 i det heile er dekt, og den lokale stien avgjer om telefonen og TV-en framleis ser kvarandre. Ei endring i éin ser fullstendig ut frå sida du står på. Skaden frå dei tre andre dukkar opp seinare, i ein annan meny, som ei anna klage.
Firmwaremenyar varierer, men dei fire stadene sjeldan. Veljaren er ei statisk mapping på DHCP-tenaren pluss ein brannmurregel som passar til henne. Resolvaren sit ved DNS-tenesta, der ein videresendarpost eller ei liste over oppstraums tenarar avgjer kva namn rutaren svarar på og kvar spørjingane går ut. Familieinnstillinga høyrer til sjølve grensesnittet, der IPv4 og IPv6 vert konfigurerte kvar for seg og ein policy berre kan dekkje den første. Den lokale stien er ein accesspunkt-brytar, anten klientisolering eller eit gjestenettverk med sin eigen brannmur.
Lat veljaren overleve leiga
Både ein policy per eining og eit dedikert segment fungerer, og det betre valet er det firmwaren kan halde ved like utan at ein annan person må hugse det. Fella er ein regel festa til ei adresse som DHCP-tenaren delte ut etter sin eigen plan: han verkar til leiga flyttar seg, og sender deretter ein laptop gjennom eit anna land av grunnar eigaren ikkje kan sjå. Vedhaldenheit, ikkje ryddigheit, er eigenskapen 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 éi endring, fordi ein regel som overlever reservasjonen sin, er ein regel retta mot andre sin maskinvare. Ein regel for eit heilt segment er den mest haldbare og grovaste veljaren, sidan kvar eining bak det grensesnittet arvar utgangen, anten ho trengde han eller ikkje. Uansett kva veljar du vel, kjem dekningsspørsmålet neste: ein policy berre for IPv4 er eit halvt vedtak, og den udekte familien er den som forsvinn ubemerka.
Finn ut kva resolvar TV-en verkeleg brukar
Opne nettverksinnstillingane til TV-en sjølv før du rører rutaren, fordi eininga avgjer denne diskusjonen. Eit DNS-felt sett til manuell held fram med å bruke den tenaren uansett kva DHCP byd, og ein set-top-boks som ein gong vart konfigurert for ein annan region, kan framleis peike på ei adresse som ikkje lenger svarar. Viss feltet er automatisk, avgjer DHCP-alternativet til rutaren, og resolvaren til rutaren sjølv vert det neste spørsmålet. Uansett er svaret på skjermen til eininga, ikkje i firmwarehandboka.
På rutarsida er skiljet som tel, mellom namn rutaren svarar på sjølv, og namn han videresender, fordi desse to stiane kan gå ut gjennom ulike grensesnitt. Eit oppslag som blir løyst rett, seier derfor ingenting om kvar ein medieførespurnad går, og på ein Linux-gateway svarar policytabellen pluss eitt enkelt ruteoppslag på båe spørsmåla utan å fange noko på TV-en:
ip rule show
ip route get 203.0.113.10Les den første kommandoen for regelen som merkjer trafikken til TV-en, og den andre for grensesnittet ein pakke til dømeadressa faktisk ville bruke. Når dei to er usamde, er det ikkje resolvaren si skuld; det er policyen. Endre éin ting, og køyr deretter paret igjen, fordi ei regelliste er ordensfølsam og ein ny post kan skugge for regelen som bar trafikken. Destinasjonen er reservert for dokumentasjon, så ein limt inn utskrift blir lesen som eit døme.
Cast bryt saman ved oppdaginga, ikkje ved straumen
Cast er minst tre samtalar, og berre éin av dei ber video. Telefonen oppdagar TV-en via multicast eller broadcast på det lokale segmentet, opnar ein kontrollkanal for å seie kva som skal spelast av, og deretter hentar TV-en straumen sjølv eller mottek han videresend frå telefonen. Oppdaging kryssar aldri ein rutar som ikkje videresender den trafikken, og det er slik ein TV kan rutast nøyaktig som tenkt og likevel aldri dukke opp i cast-lista.
Gjestenettverk og klientisolering er den vanlege årsaka, og båe gjer nøyaktig det dei vart konfigurerte til. Å slå av isolering i heile det trådlause nettverket slik at éi eining dukkar opp igjen, er den vanlege overkorrigeringa, og ho opnar igjen kvar telefon-til-telefon-sti som innstillinga fanst for å lukke. Det finst smalare svar: ein pass-regel for oppdagings- og kontrolltrafikk mellom to adresser, ein eigen SSID for TV-ane, eller eitt dokumentert unntak på gjestenettverket.
Test cast medan isoleringsregelen framleis er på plass, legg deretter berre til oppdagingsunntaket og test igjen. Viss det andre forsøket finn TV-en, er unntaket løysinga, og resten av segmentet kan bli som det var.
Stopp tunnelen og sjå kva veg han feilar
Den siste kontrollen er den dei fleste oppsett hoppar over: ta tunnelen ned og sjå om TV-en stoppar eller stille forlèt via den lokale sambindinga. Ein policy som uttrykkjer ei preferring, feilar ope, og den feilen er lett å oversjå fordi avspelinga held fram medan utgangen flyttar tilbake til ISP-en. Ein kill-switch-regel feilar lukka i staden, og TV-en rapporterer ingenting før tunnelen kjem tilbake. Ingen av dei to åtferdene er feil; det er feil å ikkje vite kva du konfigurerte.
Sjekk fire ting på nytt etter kvar endring, i denne rekkjefølgja. Veljaren passar framleis til eininga etter neste leige eller omstart. Resolvaren svarar på stien policyen siktar på, ikkje frå ein tenar eininga hugsa. Adressefamilien i policyen dekkjer kvar familie TV-en og aksessnettet faktisk brukar. Cast finn framleis TV-en frå telefonen som verkeleg skal brukast, ikkje frå ein testtelefon på same SSID.
Hald dei fire linjene ved sida av rutarkonfigurasjonen i staden for i ein chat-tråd: kva regelen matchar, kva resolvar TV-en spør, kva familie som er dekt, og kva lokal sti cast treng. Den neste personen som opnar brannmuren, les konfigurasjonen lenge før dei les ei sak. Innan den tid kan den personen vere deg.