Smart TV a la VPN: per què la transmissió i el DNS es trenquen per separat
Encamina el trànsit del televisor al router i tracta després el selector, el resolutor, l'IPv6 i el camí de transmissió com a quatre comprovacions separades.
El teu televisor mostra el catàleg estranger, i el botó de transmissió del telèfon ja no l'hi llista. Les dues queixes comencen amb una frase que anomena quatre paràmetres en quatre pàgines del router. Arregla la sortida i la descoberta es trenca; arregla la descoberta i el següent lloguer dona la sortida a un altre dispositiu. L'ordre següent va del selector fins al camí de transmissió.
On viu cadascuna de les quatre decisions
Anota les quatre abans d'obrir un menú, perquè cada una viu en una pàgina diferent i falla en un lloc diferent. El selector tria a quin client s'aplica el túnel, el resolutor decideix on es responen els noms, la família d'adreces decideix si IPv6 queda cobert o no, i el camí local decideix si el telèfon i el televisor encara es veuen. Un canvi en una sembla complet des de la pàgina on ets. El mal de les altres tres apareix més tard, en un altre menú, com una altra queixa.
Els menús del firmware varien, però les quatre ubicacions poques vegades. El selector és un mapatge estàtic al servidor DHCP més una regla de tallafoc que hi coincideix. El resolutor seu amb el servei DNS, on una entrada de reenviador o una llista de servidors upstream decideix quins noms respon el router i d'on surten les consultes. El paràmetre de família pertany a la interfície mateixa, on IPv4 i IPv6 es configuren per separat i una política només pot cobrir la primera. El camí local és un commutador del punt d'accés, o bé aïllament de clients o bé una xarxa de convidats amb el seu propi tallafoc.
Fes que el selector sobrevisqui al lloguer
Tant una política per dispositiu com un segment dedicat funcionen, i la millor elecció és la que el firmware pot mantenir sense que una segona persona l'hagi de recordar. El parany és una regla fixada a una adreça que el servidor DHCP va lliurar segons el seu propi calendari: continua funcionant fins que el lloguer es mou, i llavors encamina un portàtil per un altre país per raons que el seu amo no pot veure. La persistència, no la pulcritud, és la propietat que val la pena optimitzar.
| 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 |
Envia la reserva i la regla com un sol canvi, perquè una regla que sobreviu a la seva reserva és una regla apuntada al maquinari d'una altra persona. Una regla de segment sencer és el selector més durador i el més contundent, ja que cada dispositiu darrere d'aquella interfície hereta la sortida, tant si la necessitava com si no. Triïs el selector que triïs, la pregunta de cobertura ve després: una política només IPv4 és mitja decisió, i la família no coberta és la que marxa sense que ningú ho noti.
Esbrina quin resolutor fa servir realment el televisor
Obre la configuració de xarxa del propi televisor abans de tocar el router, perquè el dispositiu resol aquesta discussió. Un camp DNS posat en manual continua fent servir aquell servidor passi el que passi que ofereixi el DHCP, i un receptor configurat una vegada per a una altra regió encara pot apuntar a una adreça que ja no respon. Si el camp és automàtic, decideix l'opció DHCP del router, i el resolutor propi del router es converteix en la pregunta següent. En qualsevol cas la resposta és a la pantalla del dispositiu, no al manual del firmware.
A la banda del router, la distinció que importa és entre noms que el router respon ell mateix i noms que reenvia, perquè aquests dos camins poden sortir per interfícies diferents. Per tant, una consulta que es resol correctament no diu res sobre on va una petició multimèdia, i en una passarel·la Linux la taula de polítiques més una sola consulta de ruta responen les dues preguntes sense capturar res al televisor:
ip rule show
ip route get 203.0.113.10
Llegeix la primera ordre per a la regla que marca el trànsit del televisor i la segona per a la interfície que faria servir realment un paquet a l'adreça d'exemple. Quan les dues no coincideixen, el resolutor no en té la culpa; la política sí. Canvia una cosa, i torna a executar la parella, perquè una llista de regles és sensible a l'ordre i una entrada nova pot fer ombra a la regla que portava el trànsit. La destinació està reservada per a documentació, així que una sortida enganxada es llegeix com una mostra.
La transmissió es trenca a la descoberta, no al flux
La transmissió és com a mínim tres converses i només una d'elles porta vídeo. El telèfon descobreix el televisor per multicast o broadcast al segment local, obre un canal de control per dir què cal reproduir, i després el televisor o bé baixa el flux ell mateix o bé el rep retransmès des del telèfon. La descoberta no creua mai un router que no reenvia aquell trànsit, i és així com un televisor pot encaminar-se exactament com es volia i tot i així no aparèixer mai a la llista de transmissió.
Les xarxes de convidats i l'aïllament de clients són la causa habitual, i totes dues fan exactament allò per a què es van configurar. Desactivar l'aïllament a tota la xarxa sense fil perquè un dispositiu torni a aparèixer és la sobrecorrecció habitual, i reobre cada camí telèfon-a-telèfon que el paràmetre existia per tancar. Hi ha respostes més estretes: una regla de pas per al trànsit de descoberta i control entre dues adreces, una SSID separada per als televisors, o una excepció documentada a la xarxa de convidats.
Prova la transmissió amb la regla d'aïllament encara al seu lloc, i després afegeix només l'excepció de descoberta i torna a provar. Si el segon intent troba el televisor, l'excepció és la solució i la resta del segment pot quedar com estava.
Atura el túnel i mira cap a on falla
L'última comprovació és la que la majoria d'instal·lacions s'estalvien: baixa el túnel i mira si el televisor s'atura o bé marxa en silenci per la connexió local. Una política que expressa una preferència falla oberta, i aquesta fallada és fàcil de no veure perquè la reproducció continua mentre la sortida torna a l'ISP. Una regla de kill-switch falla tancada, en canvi, i el televisor no informa de res fins que el túnel torna. Cap dels dos comportaments és incorrecte; no saber quin has configurat sí que ho és.
Torna a comprovar quatre coses després de qualsevol canvi, en aquest ordre. El selector encara coincideix amb el dispositiu després del següent lloguer o reinici. El resolutor respon pel camí que la política pretén, no des d'un servidor que el dispositiu recordava. La família d'adreces de la política cobreix cada família que el televisor i la xarxa d'accés fan servir realment. La transmissió encara troba el televisor des del telèfon que s'utilitzarà de veritat, no des d'un telèfon de prova a la mateixa SSID.
Mantingues aquestes quatre línies al costat de la configuració del router i no en un fil de xat: què coincideix la regla, quin resolutor pregunta el televisor, quina família queda coberta i quin camí local necessita la transmissió. La propera persona que obri el tallafoc llegirà la configuració molt abans de llegir un tiquet. Llavors, aquesta persona pots ser tu.