Enrutamento VPN por dominio fronte a rutas IP: cal encaixa?

Unha ruta IP coincide cun prefixo de enderezo, e o núcleo aplícaa sen facer máis preguntas. Unha regra VPN baseada en dominio coincide cun nome, o que significa que algo na pila ten que decidir que enderezos significa ese nome neste momento e manter esa decisión ao día. Son mecanismos distintos con modos de fallo distintos, e os provedores usan a mesma palabra para ambos. Comparalos en listas de funcións non vai ao grao; compáraos polo que ocorre cando cambia a resposta.

A separación útil está entre unha regra que resolve e unha regra que non.

Con que coincide realmente cada regra

Unha regra de prefixo coincide cos enderezos de destino nunha táboa de enrutamento. Nada se resolve, nada caduca, e a coincidencia é exacta para cada paquete. Unha regra de dominio coincide coa petición dun nome por parte dunha aplicación, que RFC 1034 define como unha árbore de etiquetas e non como un enderezo. Algúns produtos resolven o nome unha vez e instalan os enderezos resultantes como rutas, o que converte a regra nunha regra IP cun temporizador de refresco engadido.

Saiba cal dos dous ten antes de depuralo, porque o fallo semella completamente distinto en cada caso.

Onde vive a regra de dominio na pila

Se o produto implementa as regras de dominio mediante un proxy local, o tráfico ten que chegar a ese proxy, e as aplicacións que ignoran o proxy do sistema saltan a regra por completo. Se as implementa resolvendo nomes e engadindo rutas, os enderezos son tan frescos como o último refresco. Se engancha o resolutor, o comportamento do DNS pasa a formar parte da política de enrutamento, e un resolutor de reserva pode desfacelo en silencio.

Lea o modelo do provedor e non a etiqueta do axuste. Dous clientes cunha caixa chamada Split Tunnel poden estar facendo tres cousas distintas.

Compare que se rompe

Tres cousas rompen de formas distintas. Cambio de enderezos: un nome de host de CDN pode resolverse a un conxunto de enderezos distinto en cuestión de minutos, así que unha lista copiada envellece mal. Alcance de subdominios: unha regra para example.com pode cubrir api.example.com ou non, e a documentación adoita ser explícita sobre cal é o caso. Fallo de resolución: cando o resolutor falla, un cliente que resolve pode recorrer a tunelar o tráfico ou a envialo directamente.

Só a segunda é unha cuestión de configuración. As outras dúas son cuestións de deseño sobre canto está disposto a adiviñar o produto.

Cando o prefixo é a resposta mellor

Para unha subrede privada estable, un prefixo explícito é máis claro, máis rápido e máis doado de auditar. Tamén sobrevive a unha caída do resolutor, porque nada ten que resolverse. Recorra a unha regra de dominio cando o servizo está aloxado, cando os enderezos roten ou cando realmente non pode enumerar o conxunto de destinos. Non recorra a ela só porque o nome de host é o que casualmente coñece.

Unha lista estática adiviñada é o peor de ambos: parece mantida e falla en silencio o día en que o provedor engade un host.

Verifique cunha petición nova

Probe cunha petición fría tras unha reconexión normal, porque unha páxina en caché pode non tocar nunca a regra. Resolva o nome e despois comprobe onde foi realmente a conexión. dig +short app.example.com dá o conxunto de enderezos actual, e a lista de conexións do cliente dille que interface levou o fluxo.

Repita tras o intervalo de refresco que documente o produto. Se o conxunto de enderezos se despraza e a regra non o segue, atopou o comportamento real.

Manteña tamén a política do resolutor por separado. Unha regra de dominio necesita datos de nome correctos, pero non decide por si soa que resolutor responde á consulta.