Enrutament VPN per domini enfront de rutes IP: quina encaixa?

Una ruta IP coincideix amb un prefix d'adreça, i el nucli l'aplica sense fer més preguntes. Una regla VPN basada en domini coincideix amb un nom, cosa que significa que alguna cosa de la pila ha de decidir quines adreces significa aquest nom ara mateix i mantenir aquesta decisió al dia. Són mecanismes diferents amb maneres de fallar diferents, i els proveïdors fan servir la mateixa paraula per a tots dos. Comparar-los en llistes de funcions no va al gra; compareu-los pel que passa quan canvia la resposta.

La separació útil és entre una regla que resol i una regla que no.

Amb què coincideix realment cada regla

Una regla de prefix coincideix amb les adreces de destinació d'una taula d'enrutament. No es resol res, no caduca res, i la coincidència és exacta per a cada paquet. Una regla de domini coincideix amb la petició d'un nom que fa una aplicació, que RFC 1034 defineix com un arbre d'etiquetes i no com una adreça. Alguns productes resolen el nom una vegada i instal·len les adreces resultants com a rutes, cosa que converteix la regla en una regla IP amb un temporitzador de refresc adjunt.

Sapigueu quin dels dos teniu abans de depurar-ho, perquè la fallada es veu completament diferent en cada cas.

On viu la regla de domini a la pila

Si el producte implementa les regles de domini mitjançant un proxy local, el trànsit ha d'arribar a aquest proxy, i les aplicacions que ignoren el proxy del sistema se salten la regla del tot. Si les implementa resolent noms i afegint rutes, les adreces són tan fresques com l'últim refresc. Si enganxa el resolutor, el comportament del DNS passa a formar part de la política d'enrutament, i un resolutor de reserva pot desfer-ho silenciosament.

Llegiu el model del proveïdor i no l'etiqueta de la configuració. Dos clients amb una casella anomenada Split Tunnel poden estar fent tres coses diferents.

Compareu què es trenca

Tres coses es trenquen de maneres diferents. Canvi d'adreces: un nom d'amfitrió de CDN pot resoldre's a un conjunt d'adreces diferent en qüestió de minuts, així que una llista copiada envellix malament. Abast de subdominis: una regla per a example.com pot cobrir api.example.com o no, i la documentació normalment és explícita sobre quin cas és. Fallada de resolució: quan el resolutor falla, un client que resol pot recórrer a tunelar el trànsit o a enviar-lo directament.

Només la segona és una qüestió de configuració. Les altres dues són qüestions de disseny sobre quant està disposat a endevinar el producte.

Quan el prefix és la resposta millor

Per a una subxarxa privada estable, un prefix explícit és més clar, més ràpid i més fàcil d'auditar. També sobreviu a una caiguda del resolutor, perquè no cal resoldre res. Recorreu a una regla de domini quan el servei està allotjat, quan les adreces roten o quan realment no podeu enumerar el conjunt de destinacions. No hi recorreu només perquè el nom d'amfitrió és allò que casualment coneixeu.

Una llista estàtica endevinada és el pitjor de tots dos: sembla mantinguda i falla silenciosament el trànsit el dia que el proveïdor afegeix un amfitrió.

Verifiqueu amb una petició nova

Proveu amb una petició freda després d'una reconnexió normal, perquè una pàgina en memòria cau potser no tocarà mai la regla. Resoleu el nom i després comproveu on ha anat realment la connexió. dig +short app.example.com dona el conjunt d'adreces actual, i la llista de connexions del client us diu quina interfície ha portat el flux.

Repetiu-ho després de l'interval de refresc que el producte documenta. Si el conjunt d'adreces es desplaça i la regla no el segueix, heu trobat el comportament real.

Manteniu també la política del resolutor per separat. Una regla de domini necessita dades de nom correctes, però no decideix per si sola quin resolutor respon la consulta.