DNS geogràfic i anycast: comprovar l’entrada VPN que rebeu

Una resposta DNS propera sembla un problema resolt fins que la connexió aterra en un altre lloc. El DNS geogràfic i l’anycast intenten escurçar el camí, i prenen aquesta decisió a partir d’informació diferent. Cap dels dos no garanteix que la passarel·la que assoliu sigui abastable, que presenti la identitat que el vostre client espera o que la vostra sessió sobrevisqui a un canvi de node. Les comprovacions següents separen aquestes quatre preguntes.

Comproveu de qui és la ubicació que el resolutor informa realment

Un servidor autoritatiu que respon una consulta sensible a la topologia normalment veu l’adreça del resolutor recursiu que ha preguntat, no l’adreça de la persona que ha escrit el nom. Un resolutor centralitzat pot ser lluny dels clients que serveix, i la resposta reflecteix el resolutor i no ells. Això no és cap defecte; és com es comporta el protocol tret que s’hi aporti informació addicional. Especificació d’EDNS Client Subnet descriu tant la limitació com el remei opcional.

EDNS Client Subnet pot portar informació de la xarxa d’origen quan cada participant el suporta i l’activa. És opcional, té conseqüències per a la privadesa i la memòria cau, i no és permís per suposar que qualsevol resolutor públic informa d’una ubicació precisa de l’usuari. Pregunteu als operadors de resolutors abans de dissenyar-hi al voltant.

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

Comproveu què ha decidit l’encaminament anycast

Amb anycast, diverses ubicacions anuncien abastabilitat per a una adreça de servei, i la xarxa lliura cada client al node que el seu encaminament prefereix. Aquesta tria la fan BGP i la política del voltant, no la distància en un mapa. La proximitat topològica tampoc no equival generalment a un millor rendiment d’anada i tornada, perquè el camí que sembla curt pot estar congestionat o ser asimètric. L’adreça que us han donat no diu res sobre quin node ha respost.

Confirmeu la ubicació de servei des del costat del servei, o des d’una resposta que la nomeni, i no només des de la resposta DNS. traceroute -n 198.51.100.20 mostra el camí que heu seguit i encara no nomena l’amfitrió al final, així que llegiu-lo com un camí i no com una resposta.

Comproveu que la sessió sobreviu a un canvi de node

Una consulta DNS és curta i una sessió VPN és llarga, i les dues tenen requisits d’estat completament diferents. L’encaminament pot desplaçar-se a mig camí de la sessió, i quan ho fa, els paquets posteriors poden arribar a un node que mai no ha vist el vostre túnel. Si això és sobrevivable depèn de la implementació: estat compartit, una reconnexió deliberada o un falliment documentat. L’adreça sola no n’aporta cap.

Observeu el desplaçament en lloc de suposar-lo. sudo tcpdump -ni any -c 20 esp mostra els paquets exteriors a mesura que el camí canvia, i un canvi sobtat en l’adreça del parell és el desplaçament que s’esdevé. Definiu explícitament el comportament volgut per a la implementació que executeu, i després proveu-lo forçant un canvi de camí. Si el disseny pressuposa replicació de sessió, nomeneu el mecanisme i nomeneu el falliment que no cobreix.

Comproveu que la identitat encara coincideix

Cada punt d’entrada ha de presentar la identitat que el vostre perfil de client espera. Un certificat emès per al nom del servei funciona a tots els nodes, mentre que els certificats per node obliguen el client a acceptar una cosa nova, i és aquí on els usuaris aprenen a clicar a través dels avisos. Mantingueu la identitat esperada i el perfil coherents amb el model d’entrada.

Comproveu-ho des d’un client que ha arribat a un node inusual, perquè és el cas en què un certificat per node es fa visible. openssl s_client -connect vpn.example.com:443 -servername vpn.example.com imprimeix la cadena i els noms, que és exactament el que compara el client. Després decidiu si cal estrényer el perfil o canviar el model de certificat.

Comproveu el registre, no només la primera resposta

Avalueu tres escenaris i escriviu quatre fets per a cadascun: entrada normal, una ubicació no disponible i el cas de recuperació acordat. Els quatre fets són el resolutor emprat, l’adreça retornada, la ubicació que ha servit i un resultat fresc de l’aplicació. Aquest registre separa un problema de selecció DNS d’un problema de passarel·la, d’encaminament o d’estat de sessió. Sense això, tots quatre semblen idèntics des del client.

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

Executeu els escenaris des de xarxes d’accés representatives i no només des de l’oficina, perquè tota la qüestió és a quin punt d’entrada arriben realment els diferents clients. Una xarxa és una mostra d’una.