Interruptor d'emergència després d'un canvi de Wi-Fi a mòbil: què es trenca

En un moment l'ordinador portàtil és a la Wi-Fi de l'oficina, al següent està connectat a un telèfon, i l'indicador del túnel torna a ser verd abans que acabeu de canviar de finestra. La llum verda només informa que el túnel s'ha tornat a connectar; què va fer la política d'encaminament i bloqueig durant el buit és una altra pregunta. Aquesta política és un conjunt de condicions de coincidència compilades quan es va instal·lar per última vegada, i anomena una interfície, una adreça i una família d'adreces que el relleu acaba de suprimir. El mateix canvi, doncs, produeix tres resultats que semblen idèntics: el bloqueig continua, la política bloqueja la seva pròpia recuperació, o s'obre un camí que res no cobreix.

Res a la pantalla no separa aquests tres estats, així que pregunteu a quins identificadors estaven lligades les regles en lloc de quin color mostra l'indicador. A Linux una regla pot anomenar una interfície o un ipset omplert des d'una; a Android es pot dir a un VpnService quines xarxes subjacents ha de seguir mitjançant setUnderlyingNetworks. Cada lligam apunta a un enllaç que està a punt de ser substituït, i cada un s'ha de tornar a avaluar després.

Què reescriu realment el relleu

Quan l'enllaç antic desapareix, el nucli n'elimina les adreces, retira les rutes que hi passaven i reconstrueix la selecció d'adreça d'origen amb el que queda. La ruta per defecte es mou a la nova porta d'enllaç, i l'índex d'interfície a què feien referència les regles antigues ha desaparegut o s'ha reciclat per a un altre dispositiu. Els resolutors per enllaç també es refresquen, encara que no en el mateix instant que les rutes. Tot això passa per sota del client VPN, així que un client que només vigila l'estat del seu túnel no en veu res.

El problema és que una regla codifica un identificador concret en lloc de la intenció que hi ha darrere. Una regla que descarta tot el que no surt per la interfície del túnel codifica un nom d'interfície; una regla que permet el punt final codifica una adreça que la nova xarxa pot encaminar a un altre lloc. Quan l'identificador desapareix, la regla no es torna visiblement incorrecta: o deixa de coincidir amb res o comença a coincidir amb la cosa equivocada.

Reconstruir el túnel exterior sense fer un forat

El transport exterior estava lligat a l'adreça d'origen antiga, així que ha d'obrir un socket nou des de la nova. Quan el punt final és un nom d'amfitrió i no una adreça literal, una consulta ha de reeixir mentre el bloqueig encara és vigent. Aquest és el parany de l'ordre: una política prou estricta per descartar-ho tot excepte el punt final també descartarà la consulta necessària per trobar-lo, tret que la resolució passi abans que s'aixequi el bloqueig o es porti per un túnel que encara és viu. Qualsevol dels dos ordres pot funcionar, però només si el client sap en quin ordre és.

Els clients difereixen aquí d'una manera que importa quan diagnostiqueu. Alguns resolen primer i instal·len les regles després, així que un relleu costa una interrupció visible i després es recupera sol; d'altres mantenen el bloqueig i depenen del túnel supervivent per portar la consulta, cosa que falla del tot quan el túnel ha mort amb l'enllaç. Afegir una ruta directa per defecte àmplia per restaurar la connectivitat sempre fa passar la prova i sempre deixa l'escletxa que volíeu evitar.

Una ruta que encara apunta a la porta d'enllaç antiga dóna la mateixa recuperació encallada per una causa diferent, així que llegiu la taula abans de culpar el client. Les ordres de sota anomenen la interfície i l'adreça d'origen que el nucli faria servir de debò, cosa que resol en una línia si el camí antic encara és instal·lat.

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Quan el nou enllaç porta IPv6 i les regles no

Les xarxes mòbils i de convidats sovint reparteixen un prefix IPv6 global encara que la LAN cablejada de l'oficina mai no ho hagi fet. Una política escrita només com a regles IPv4, la forma per defecte de la majoria de receptes fetes a mà d'iptables i nftables, no en cobreix res. El túnel continua connectat, les aplicacions amb abast IPv6 en surten fora, i l'indicador no pot mostrar la diferència perquè el túnel realment està aixecat. El cas mirall és igual de comú: un conjunt de regles només per a IPv6 no fa res en una xarxa que no ofereix v6.

Compareu què ofereix l'enllaç amb què esmenta la política, als dos costats del relleu. Aquestes ordres imprimeixen els mateixos fets amb què treballa el client:

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

Si la segona ordre imprimeix una ruta per defecte mentre la tercera retorna zero, el nou enllaç pot fer sortir la màquina per IPv6 sense cap regla que ho vigili. Torneu a executar les tres després del canvi, perquè el número interessant és la diferència entre les dues execucions. Si la segona no imprimeix res, s'aplica el cas invers i qualsevol política carregada de v6 allà és només decoració.

El resolutor canvia de mans a mig sessió

En els sistemes moderns els resolutors van lligats als enllaços, així que un enllaç nou arriba amb un conjunt de resolutors nou i potser una vista de split-DNS diferent. systemd-resolved manté un àmbit per enllaç i tria entre ells per ruta, mentre que macOS llegeix resolutors amb àmbit del magatzem dinàmic i respecta l'ordre d'interfícies. Un client que instal·la el seu propi resolutor competeix amb el de l'enllaç, i les regles de prioritat que ningú no mira decideixen el guanyador. Aleshores la resolució de noms pot trencar-se mentre el filtratge de paquets fa exactament allò per a què es va escriure.

Llegiu el resolutor que és actiu, no el que està configurat. En un amfitrió systemd la subordre status mostra d'on ve cada àmbit i si hi ha un nom private-DNS en vigor:

resolvectl status --no-pager
resolvectl query intranet.example.com

Si la consulta surt per l'enllaç físic en lloc del túnel, el client ha perdut la competició de prioritat i cap ajust del tallafoc arreglarà l'anomenament. Compareu el camí de la consulta als dos costats del relleu per veure quin s'ha mogut. Un nom que resol a una adreça privada que la nova xarxa no pot encaminar és un tercer cas, i es presenta com a temps d'espera i no com a error.

Assageu el relleu i guardeu el registre

Reproduïu el canvi a propòsit en lloc d'esperar-lo. Aixequen el túnel al primer enllaç, engegueu una transferència llarga i una consulta repetida, després canvieu l'enllaç i observeu quin sobreviu. Anoteu l'interval entre la desaparició de l'enllaç antic i l'informe del túnel que està connectat, perquè en aquesta finestra la política o va aguantar o no. Feu la seqüència també en l'altra direcció, perquè el resultat no sigui unilateral.

Les excepcions necessiten el seu propi pas, perquè un bypass justificat a la xarxa antiga no queda justificat automàticament a la nova. Una impressora, un NAS o un portal captiu a la LAN de casa no tenen equivalent al mòbil, i l'excepció que hi arribava esdevé una regla sense equivalent.

Anoteu els noms d'interfície, les famílies ofertes, el resolutor en vigor i la durada de la interrupció per a cada direcció. Una reconnexió demostra que el transport s'ha recuperat, no que el bloqueig aguantés durant el buit, i són afirmacions separades per posar en un tiquet. Amb aquest registre el proper relleu es compara amb un estat conegut i no amb la memòria.