Unha regra de dominio VPN rompe cando un CDN cambia as súas direccións
Unha resposta DNS é unha instantánea, non un inventario. Tres condicións deciden se unha regra baseada no nome ou un prefixo explícito encaixa nun servizo con CDN.
Copias a dirección dunha consulta na túa regra de encamiñamento, o sitio funciona e unha semana despois xa non. Nada da regra cambiou. O servizo moveuse a outra dirección de bordo, o cliente resolveu outro nome de host ou a sesión pasou a IPv6. A decisión que tes diante é se unha regra baseada no nome ou un rango explícito é o instrumento axeitado para este servizo, e tres condicións resólveno. O que segue separa o nome da dirección, porque só un dos dous é estable.
Por que unha consulta non é un inventario
Unha rede de distribución de contidos responde cunha dirección escollida para o resolutor, a rexión e o momento. Pregunta dúas veces desde redes distintas e podes obter respostas distintas. Pregunta unha vez e trata a resposta como a lista de direccións do servizo, e a regra que escribas será unha instantánea, non unha regra. Ese é todo o problema de tratar unha resposta DNS como configuración.
Hai unha segunda lagoa. Un só nome de host visible raramente cobre toda a aplicación, porque o inicio de sesión, os medios e o tráfico de API adoitan usar nomes separados. Unha regra construída a partir do nome de host da barra de enderezos pode cubrir a páxina e perder o vídeo, o que se le como un fallo parcial e non como un erro de encamiñamento.
A terceira lagoa é a familia de direccións. Unha regra só para v4 non di nada sobre o rexistro AAAA que o cliente pode preferir.
Tres condicións que deciden regra de dominio ou rangos
Primeiro, o servizo publica un conxunto estable de prefixos que poidas posuír e documentar? Se o fai, os rangos explícitos son honestos e baratos. Se non o fai, unha regra de dominio é o único mecanismo que pode seguir o servizo.
Segundo, actualízase o mecanismo de dominio do teu cliente? Unha regra que se resolve unha vez ao conectar e nunca máis é unha instantánea con mellor imaxe de marca. Terceiro, o mecanismo cobre subdominios e as dúas familias de direccións, ou só os nomes que escribiches?
Responde esas tres e a elección adoita ser obvia. Adiviñar produce unha regra que funciona en probas e falla en produción.
Proba unha sesión, non unha páxina
Carga a páxina e despois realiza a operación que importa: iniciar sesión, comezar a reprodución, subir un ficheiro. Cada unha pode chegar a un host distinto, e a que falla é a que a túa regra pasou por alto.
Enumera con que contacta realmente a sesión en lugar de que mostra a páxina:
dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5Mantén visible o resolutor durante a comparación, porque unha regra que funciona desde un resolutor e falla desde outro fálache da resposta do CDN, non do túnel. Un TTL curto tamén significa que a resposta que rexistraches ten data de caducidade.
Que cobre realmente cada mecanismo
Os dous mecanismos parecen intercambiables nunha páxina de axustes e compórtanse de forma distinta por dentro.
| Mechanism | What it matches | How it fails |
|---|---|---|
| Domain rule | Names the client resolves, then their addresses | Misses subdomains, or goes stale when refresh is off |
| Address route | A prefix you wrote down | Keeps matching an address the service has left |
Unha ruta de dirección do núcleo fai coincidir prefixos. Non ten idea do que é un nome de host, así que non pode seguir un servizo que cambia de direccións. Unha regra de dominio resolve nomes e encamiña o resultado; segue o servizo, pero depende do resolutor, do comportamento de actualización e do tratamento dos subdominios por parte do cliente, así que unha regra que segue nomes debe probarse co resolutor que o cliente usa realmente.
Ningunha é un superconxunto da outra, e por iso mesturalas sen unha nota xera confusión máis adiante.
Volve comprobar cando o servizo cambie
Tras unha actualización do cliente ou un cambio do servizo, executa de novo a mesma proba de sesión. Unha lista de direccións que antes funcionaba é evidencia daquel período, non un inventario permanente da infraestrutura do servizo.
Anota que mecanismo cobre que nome de host e a data da última verificación.
Esa nota é a diferenza entre unha regra que podes defender e unha regra que ninguén se atreve a tocar. Se o servizo publica a súa propia lista de prefixos, úsaa e cita a data. Se non o fai, dillo, e mantén a regra de dominio co seu comportamento de actualización escrito ao lado.