Smart TV în VPN: de ce castingul și DNS-ul se strică separat

Televizorul dumneavoastră afișează catalogul străin, iar butonul de casting al telefonului nu îl mai listează. Ambele reclamații încep cu o propoziție care numește patru setări pe patru pagini ale routerului. Remediați ieșirea și descoperirea se strică; remediați descoperirea și următorul lease dă ieșirea altui dispozitiv. Ordinea de mai jos merge de la selector la calea de casting.

Unde locuiește fiecare dintre cele patru decizii

Notați-le pe toate patru înainte de a deschide un meniu, pentru că fiecare locuiește pe altă pagină și eșuează în alt loc. Selectorul alege cărui client i se aplică tunelul, resolverul decide unde se răspunde la nume, familia de adrese decide dacă IPv6 este deloc acoperit, iar calea locală decide dacă telefonul și televizorul încă se văd. O modificare la una pare completă din pagina în care stați. Paguba celorlalte trei apare mai târziu, în alt meniu, ca altă reclamație.

Meniurile firmware diferă, dar cele patru locații rareori. Selectorul este o mapare statică pe serverul DHCP plus o regulă de firewall care i se potrivește. Resolverul stă lângă serviciul DNS, unde o intrare de forwarder sau o listă de servere din amonte decide căror nume le răspunde routerul și de unde pleacă interogările. Setarea de familie aparține interfeței înseși, unde IPv4 și IPv6 se configurează separat și o politică poate acoperi doar prima. Calea locală este un comutator al punctului de acces, fie izolarea clienților, fie o rețea de oaspeți cu propriul firewall.

Faceți selectorul să supraviețuiască lease-ului

Funcționează atât o politică pe dispozitiv, cât și un segment dedicat, iar alegerea mai bună este cea pe care firmware-ul o poate întreține fără ca o a doua persoană să o țină minte. Capcana este o regulă fixată pe o adresă pe care serverul DHCP a dat-o după propriul program: funcționează până când lease-ul se mută, apoi direcționează un laptop prin altă țară din motive pe care proprietarul nu le vede. Persistența, nu ordinea, este proprietatea care merită optimizată.

Trimiteți rezervarea și regula ca o singură modificare, pentru că o regulă care supraviețuiește rezervării sale este o regulă îndreptată spre hardware-ul altcuiva. O regulă pentru un segment întreg este cel mai durabil și cel mai grosolan selector, fiindcă fiecare dispozitiv din spatele acelei interfețe moștenește ieșirea, fie că avea nevoie de ea, fie că nu. Indiferent de selectorul ales, întrebarea acoperirii vine în continuare: o politică doar IPv4 este jumătate de decizie, iar familia neacoperită este cea care pleacă neobservată.

Aflați ce resolver folosește televizorul cu adevărat

Deschideți setările de rețea ale televizorului însuși înainte de a atinge routerul, pentru că dispozitivul încheie această dispută. Un câmp DNS setat manual continuă să folosească acel server orice ar oferi DHCP, iar un set-top box configurat cândva pentru altă regiune poate încă indica o adresă care nu mai răspunde. Dacă câmpul este automat, decide opțiunea DHCP a routerului, iar resolverul propriu al routerului devine următoarea întrebare. În orice caz, răspunsul este pe ecranul dispozitivului, nu în manualul firmware-ului.

Pe partea routerului, distincția care contează este între numele la care routerul răspunde singur și numele pe care le transmite, pentru că aceste două căi pot ieși prin interfețe diferite. De aceea o interogare rezolvată corect nu spune nimic despre unde merge o cerere media, iar pe un gateway Linux tabela de politici plus o singură căutare de rută răspund la ambele întrebări fără a captura nimic pe televizor:

ip rule show
ip route get 203.0.113.10

Citiți prima comandă pentru regula care marchează traficul televizorului și pe a doua pentru interfața pe care un pachet către adresa exemplu ar folosi-o efectiv. Când cele două nu sunt de acord, vinovat nu este resolverul, ci politica. Schimbați un lucru, apoi rulați din nou perechea, pentru că o listă de reguli este sensibilă la ordine și o intrare nouă poate umbri regula care ducea traficul. Destinația este rezervată pentru documentație, așa că o ieșire lipită se citește ca exemplu.

Castingul se strică la descoperire, nu la flux

Castingul este cel puțin trei conversații și doar una dintre ele transportă video. Telefonul descoperă televizorul prin multicast sau broadcast în segmentul local, deschide un canal de control pentru a spune ce să ruleze, iar apoi televizorul fie preia fluxul singur, fie îl primește transmis de la telefon. Descoperirea nu traversează niciodată un router care nu transmite acel trafic, și astfel un televizor poate fi direcționat exact cum s-a intenționat și totuși să nu apară niciodată în lista de casting.

Rețelele de oaspeți și izolarea clienților sunt cauza obișnuită, și ambele fac exact ceea ce au fost configurate să facă. Oprirea izolării în întreaga rețea fără fir pentru ca un dispozitiv să reapară este supra-corectarea obișnuită, și redeschide fiecare cale telefon-la-telefon pe care setarea exista să o închidă. Există răspunsuri mai înguste: o regulă de trecere pentru traficul de descoperire și control între două adrese, un SSID separat pentru televizoare sau o singură excepție documentată în rețeaua de oaspeți.

Testați castingul cu regula de izolare încă la loc, apoi adăugați doar excepția de descoperire și testați din nou. Dacă a doua încercare găsește televizorul, excepția este soluția, iar restul segmentului poate rămâne cum era.

Opriți tunelul și urmăriți în ce direcție eșuează

Ultima verificare este cea pe care majoritatea configurațiilor o sar: coborâți tunelul și urmăriți dacă televizorul se oprește sau pleacă în liniște prin conexiunea locală. O politică ce exprimă o preferință eșuează deschis, iar eșecul este ușor de ratat pentru că redarea continuă în timp ce ieșirea se întoarce la ISP. O regulă kill-switch eșuează închis, iar televizorul nu raportează nimic până când tunelul revine. Niciunul dintre cele două comportamente nu este greșit; să nu știți pe care l-ați configurat este.

Verificați din nou patru lucruri după orice modificare, în această ordine. Selectorul se potrivește în continuare dispozitivului după următorul lease sau repornire. Resolverul răspunde pe calea pe care politica o intenționează, nu de la un server pe care dispozitivul și l-a amintit. Familia de adrese din politică acoperă fiecare familie pe care televizorul și rețeaua de acces o folosesc efectiv. Castingul găsește în continuare televizorul de pe telefonul care va fi folosit cu adevărat, nu de pe un telefon de test în același SSID.

Țineți cele patru rânduri lângă configurația routerului, nu într-un fir de chat: ce potrivește regula, ce resolver întreabă televizorul, ce familie este acoperită și ce cale locală are nevoie castingul. Următoarea persoană care deschide firewall-ul va citi configurația mult înainte de a citi un tichet. Până atunci, acea persoană ați putea fi dumneavoastră.