Una regola di dominio VPN si rompe quando un CDN cambia i suoi indirizzi
Una risposta DNS è un'istantanea, non un inventario. Tre condizioni decidono se una regola basata sul nome o un prefisso esplicito si adatta a un servizio con CDN.
Copi l'indirizzo da una ricerca nella tua regola di routing, il sito funziona e una settimana dopo non più. Nulla della regola è cambiato. Il servizio si è spostato su un altro indirizzo di bordo, il client ha risolto un altro nome host o la sessione è passata a IPv6. La decisione davanti a te è se una regola basata sul nome o un intervallo esplicito sia lo strumento giusto per questo servizio, e tre condizioni lo stabiliscono. Quanto segue separa il nome dall'indirizzo, perché solo uno dei due è stabile.
Perché una ricerca non è un inventario
Una rete di distribuzione dei contenuti risponde con un indirizzo scelto per il resolver, la regione e il momento. Chiedi due volte da reti diverse e puoi ottenere risposte diverse. Chiedi una volta e tratta la risposta come la lista di indirizzi del servizio, e la regola che scrivi è un'istantanea, non una regola. È tutto il problema del trattare una risposta DNS come configurazione.
C'è una seconda lacuna. Un solo nome host visibile raramente copre l'intera applicazione, perché accesso, media e traffico API usano spesso nomi separati. Una regola costruita dal nome host nella barra degli indirizzi può coprire la pagina e mancare il video, cosa che si legge come un guasto parziale e non come un errore di routing.
La terza lacuna è la famiglia di indirizzi. Una regola solo per v4 non dice nulla sul record AAAA che il client potrebbe preferire.
Tre condizioni che decidono regola di dominio o intervalli
Primo, il servizio pubblica un insieme stabile di prefissi che puoi possedere e documentare? Se sì, gli intervalli espliciti sono onesti ed economici. Se no, una regola di dominio è l'unico meccanismo che può seguire il servizio.
Secondo, il meccanismo di dominio del tuo client si aggiorna? Una regola che si risolve una volta alla connessione e mai più è un'istantanea con un'immagine migliore. Terzo, il meccanismo copre sottodomini ed entrambe le famiglie di indirizzi, o solo i nomi che hai digitato?
Rispondi a queste tre e la scelta di solito è ovvia. Tirare a indovinare produce una regola che funziona in prova e fallisce in produzione.
Prova una sessione, non una pagina
Carica la pagina, poi esegui l'operazione che conta: accedi, avvia la riproduzione, carica un file. Ognuna può raggiungere un host diverso, e quella che fallisce è quella che la tua regola ha mancato.
Elenca ciò con cui la sessione comunica davvero invece di ciò che la pagina mostra:
dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5Tieni visibile il resolver durante il confronto, perché una regola che funziona da un resolver e fallisce da un altro ti parla della risposta del CDN, non del tunnel. Un TTL breve significa anche che la risposta che hai registrato ha una scadenza.
Cosa copre davvero ciascun meccanismo
I due meccanismi sembrano intercambiabili in una pagina di impostazioni e si comportano diversamente sotto.
| 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 rotta di indirizzo del kernel confronta prefissi. Non ha idea di cosa sia un nome host, quindi non può seguire un servizio che cambia indirizzi. Una regola di dominio risolve nomi e instrada il risultato; segue il servizio ma dipende dal resolver, dal comportamento di aggiornamento e dalla gestione dei sottodomini da parte del client, quindi una regola che segue i nomi va provata con il resolver che il client usa davvero.
Nessuna delle due è un sovrainsieme dell'altra, ed è per questo che mescolarle senza una nota crea confusione più avanti.
Ricontrolla dopo che il servizio cambia
Dopo un aggiornamento del client o un cambiamento del servizio, esegui di nuovo la stessa prova di sessione. Una lista di indirizzi che prima funzionava è una prova per quel periodo, non un inventario permanente dell'infrastruttura del servizio.
Annota quale meccanismo copre quale nome host e la data dell'ultima verifica.
Quella nota è la differenza tra una regola che puoi difendere e una regola che nessuno osa toccare. Se il servizio pubblica la propria lista di prefissi, usala e cita la data. Se non lo fa, dillo, e tieni la regola di dominio con il suo comportamento di aggiornamento scritto accanto.