Dos VPN i un sol resolutor: guanya qui escriu l’últim

Hi ha dos clients VPN connectats, un per a la feina i un altre per a una xarxa de laboratori, i els noms interns només es resolen per al client que s’ha connectat l’últim. Aquest patró sembla un error en un dels clients. Normalment és el resultat previsible de dos programes que escriuen la mateixa configuració de resolutor sense cap acord sobre qui posseeix cada nom.

El mite: el VPN més nou posseeix el DNS

No hi ha cap regla general que faci guanyar la connexió més recent. El que passa depèn del mecanisme de la plataforma i de com l’escriu cada client. Un client que substitueix un fitxer de resolutor produeix un resultat; un client que afegeix un domini per enllaç en produeix un altre; un client que no fa res deixa intacte l’estat anterior.

Així, el comportament observat és una propietat de les dues implementacions, no una prioritat documentada. Raonar-ne només a partir de l’ordre d’inici serà de vegades correcte i de vegades equivocat de maneres difícils de reproduir. Escriu la correspondència. Un disseny que viu en dos clients no és un disseny.

Assigna espais de noms als resolutors

Llista els sufixos privats i el resolutor que exigeix cada xarxa, i després decideix on han d’anar els noms públics. Aquesta llista és el disseny. Sense ella, els clients prenen la decisió per accident.

Una plataforma que admet DNS per enllaç o dominis d’encaminament pot expressar la divisió deliberadament: un domini va a un enllaç, un altre domini a l’altre, i tota la resta segueix un valor predeterminat explícit. Dos scripts plans que sobreescriuen el mateix fitxer no poden conservar aquest disseny, perquè cadascun creu que posseeix tota la configuració.

A Windows, la taula de política de resolució de noms pot dirigir sufixos a servidors concrets, i un client VPN pot instal·lar-hi regles. Comprova la política en lloc de la llista d’adaptadors, perquè la llista d’adaptadors no és el que resol el nom.

Mantingues una ruta d’arrencada

Cada client ha de localitzar el seu propi punt final abans de poder utilitzar el servei que aquest punt final ofereix. Si el nom d’amfitrió del punt final només es pot resoldre a través del túnel, i el túnel necessita el nom d’amfitrió resolt, tens una dependència circular que apareix com un temps d’espera de connexió. Mantingues una ruta d’arrencada fora dels dos túnels. No costa res fins al dia que salva la connexió.

Mira el camí cap a cada resolutor, no només el nom configurat per a ell. Un resolutor que només és abastable a través de l’altre túnel es comporta com un que falta, i el símptoma és un temps d’espera en lloc d’un error d’encaminament.

Les adreces superposades no són un problema de DNS

Dues xarxes privades que utilitzen el mateix rang d’adreces no es poden arreglar amb l’ordre del DNS. Si tots dos túnels reclamen 10.0.0.0/8, un nom que es resol correctament encara apunta a una adreça que l’amfitrió no pot encaminar cap al túnel correcte. Això necessita una solució a nivell d’adreça, com ara rangs diferents, un espai de noms o traducció, no una altra configuració de resolutor. Decidir-ho aviat evita un llarg desviament per una configuració de DNS que mai no hauria funcionat.

Compara les assignacions d’adreces dels dos túnels abans de culpar la resolució de noms. Quan els dos extrems empenyen el mateix prefix, l’amfitrió en conserva una sola ruta, i un nom resolt a través del segon túnel encara acaba en una adreça que posseeix el primer túnel. Rangs diferents, un espai de noms per xarxa o traducció són les solucions; després que cada client es connecti, confirma que la taula d’encaminament mostra el camí que volies.

Prova-ho amb aplicacions reals

Tria dos amfitrions que només existeixin dins del seu propi espai de noms i un nom públic, i després resol cadascun a través del client que l’hauria de posseir. Una resposta correcta del resolutor esperat no demostra que l’aplicació arribi a l’amfitrió, perquè la ruta cap a aquesta adreça encara pot fallar. Acompanya cada consulta amb una prova de connexió des del programa que l’usuari executarà realment.

Un client amb la seva pròpia opció de DNS xifrat pot saltar-se la política que acabes de verificar, així que revisa aquest paràmetre com a part de la revisió. Després reconnecta tots dos clients en l’ordre que admet el proveïdor i repeteix les consultes; si les respostes s’intercanvien quan canvia l’ordre, un escriptor competidor encara posseeix part de la configuració. Esbrina quin component instal·la la regla - el client, el perfil del sistema operatiu o un agent de gestió - abans de modificar res. Anota l’ordre i els propietaris perquè la propera persona no els hagi de redescobrir.