Una regla de domini VPN deixa de funcionar quan un CDN canvia les seves adreces
Una resposta DNS és una instantània, no un inventari. Tres condicions decideixen si una regla basada en el nom o un prefix explícit encaixa amb un servei amb CDN.
Copieu l’adreça d’una consulta a la vostra regla d’encaminament, el lloc funciona i, una setmana després, ja no. Res de la regla no ha canviat. El servei s’ha mogut a una altra adreça de vora, el client ha resolt un altre nom d’amfitrió o la sessió ha passat a IPv6. La decisió que teniu davant és si una regla basada en el nom o un rang explícit és l’instrument adequat per a aquest servei, i tres condicions ho resolen. El que segueix separa el nom de l’adreça, perquè només un dels dos és estable.
Per què una consulta no és un inventari
Una xarxa de distribució de continguts respon amb una adreça triada per al resolutor, la regió i el moment. Pregunteu dues vegades des de xarxes diferents i podeu obtenir respostes diferents. Pregunteu una vegada i tracteu la resposta com la llista d’adreces del servei, i la regla que escriviu serà una instantània, no una regla. Aquest és tot el problema de tractar una resposta DNS com a configuració.
Hi ha una segona llacuna. Un sol nom d’amfitrió visible poques vegades cobreix tota l’aplicació, perquè l’inici de sessió, els mitjans i el trànsit d’API sovint fan servir noms separats. Una regla construïda a partir del nom d’amfitrió de la barra d’adreces pot cobrir la pàgina i perdre el vídeo, cosa que es llegeix com un fracàs parcial i no com un error d’encaminament.
La tercera llacuna és la família d’adreces. Una regla només per a v4 no diu res sobre el registre AAAA que el client pot preferir.
Tres condicions que decideixen regla de domini o rangs
Primer, el servei publica un conjunt estable de prefixos que pugueu posseir i documentar? Si ho fa, els rangs explícits són honestos i barats. Si no ho fa, una regla de domini és l’únic mecanisme que pot seguir el servei.
Segon, la regla de domini del vostre client s’actualitza? Una regla que es resol una vegada en connectar-se i mai més és una instantània amb millor imatge de marca. Tercer, el mecanisme cobreix subdominis i les dues famílies d’adreces, o només els noms que heu escrit?
Responeu aquestes tres i l’elecció sol ser òbvia. Endevinar produeix una regla que funciona en proves i falla en producció.
Proveu una sessió, no una pàgina
Carregueu la pàgina i feu l’operació que importa: inicieu sessió, comenceu la reproducció, pugeu un fitxer. Cadascuna pot arribar a un amfitrió diferent, i la que falla és la que la vostra regla ha perdut.
Enumereu què contacta realment la sessió en lloc de què mostra la pàgina:
dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5Mantingueu el resolutor visible durant la comparació, perquè una regla que funciona des d’un resolutor i falla des d’un altre us parla de la resposta del CDN, no del túnel. Un TTL curt també vol dir que la resposta que heu registrat té data de caducitat.
Què cobreix realment cada mecanisme
Els dos mecanismes semblen intercanviables en una pàgina de configuració i es comporten de manera diferent per dins.
| 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 |
Una ruta d’adreça del nucli fa coincidir prefixos. No té cap idea de què és un nom d’amfitrió, així que no pot seguir un servei que canvia d’adreces. Una regla de domini resol noms i encamina el resultat; segueix el servei, però depèn del resolutor, del comportament d’actualització i del tractament dels subdominis per part del client, així que una regla que segueix noms s’ha de provar amb el resolutor que el client fa servir realment.
Cap de les dues no és un superconjunt de l’altra, i per això barrejar-les sense una nota genera confusió més endavant.
Torneu a comprovar després que el servei canviï
Després d’una actualització del client o d’un canvi del servei, torneu a executar la mateixa prova de sessió. Una llista d’adreces que abans funcionava és evidència d’aquell període, no un inventari permanent de la infraestructura del servei.
Anoteu quin mecanisme cobreix quin nom d’amfitrió i la data de l’última verificació.
Aquesta nota és la diferència entre una regla que podeu defensar i una regla que ningú no gosa tocar. Si el servei publica la seva pròpia llista de prefixos, feu-la servir i citeu la data. Si no ho fa, digueu-ho, i manteniu la regla de domini amb el seu comportament d’actualització escrit al costat.