Dove esce davvero l’uscita internet della vostra VPN gestita
«Internet incluso» non dice nulla su dove esce il traffico pubblico, chi lo filtra o cosa sopravvive a un guasto. Seguite il percorso, poi scrivete entrambi i casi di guasto.
Non potete dire chi filtra il traffico pubblico di una filiale finché la proposta non mostra da dove quel traffico lascia la rete del fornitore. L’accesso a internet incluso in una VPN gestita è un secondo servizio, che percorre un cammino con i propri gateway, la propria traduzione degli indirizzi e la propria coda di escalation. La maggior parte dei contratti descrive il lato privato in dettaglio e lascia il lato pubblico a una frase. I controlli qui sotto trasformano quella frase in uno schema che potete difendere.
Seguite una destinazione pubblica per sito
Scegliete un host di una filiale e seguite una destinazione pubblica, annotando l’ultimo indirizzo che appartiene al fornitore e il primo che appartiene a internet. Il salto tra quei due indirizzi è l’uscita, e spesso non si trova affatto vicino al sito che ha inviato il pacchetto. Marcate il dispositivo che effettua la transizione, perché è quel dispositivo a tenere il filtro che decide cosa esce. Ripetete la traccia da un secondo sito e confrontate gli indirizzi di uscita, perché due filiali identiche in fattura possono uscire da gateway diversi in città diverse.
Annotate anche l’indirizzo sorgente che la destinazione vede davvero, perché la traduzione può avvenire su un salto che non avete mai disegnato. Scrivete le risposte osservate accanto a quelle disegnate, e lo scarto tra le due è il punto da cui arriverà il primo incidente. Un ingegnere del fornitore che non sa fornire l’indirizzo di uscita di un dato sito vi ha già detto qualcosa di utile sul progetto.
Tre disposizioni di uscita e che cosa concentra ciascuna
Un’uscita centrale che gestite voi attira il traffico pubblico su un gateway vostro, il che vi dà la politica di filtraggio e i registri ma concentra il carico di tutti i siti su un solo circuito. Un’uscita gestita dal fornitore sposta politica e registri oltre il confine contrattuale, il che semplifica le operazioni e vi toglie la visibilità nello stesso gesto. Un’uscita su ogni sito mantiene il traffico pubblico locale e moltiplica il numero di superfici di politica che devono restare identiche.
| Arrangement | Blast radius of one failure | Address a partner allowlists |
|---|---|---|
| Central exit you operate | Every site, through one circuit and one team | Your own exit pool |
| Provider-run exit | Their shared gateway and its change window | Their NAT pool, often shared |
| Exit at each site | One branch, one local device | Each site's local address |
Chiedete quale delle tre il fornitore offre davvero prima di trattare l’elenco come un menu, e chiedete se un sito può passare dall’una all’altra senza un nuovo circuito. La risposta sulla migrazione separa ciò che è contrattuale da ciò che è solo tecnico. Annotate anche chi possiede la traduzione degli indirizzi sorgente, perché questo decide cosa un partner deve mettere nella lista di autorizzazione. I gateway condivisi significano anche capacità condivisa e talvolta reputazione condivisa, il che cambia il modo in cui i partner trattano i vostri indirizzi. Anche la capacità merita una domanda propria, perché un gateway condiviso sta servendo altri clienti nello stesso momento.
Filtraggio, traduzione e cifratura hanno proprietari distinti
Una rotta stabilisce la raggiungibilità e non dice nulla sull’ispezione, quindi trattate le due cose come domande diverse con proprietari diversi. Per ogni rotta predefinita annunciata, nominate il dispositivo che filtra, quello che autentica, quello che traduce e quello che ispeziona, poi nominate chi amministra ciascuno. La separazione delle rotte del fornitore non dice dove termina la cifratura, e un servizio privato può chiudere il proprio tunnel a un confine mentre l’uscita pubblica termina a un altro. Chiedete se la traduzione avviene al bordo del fornitore, su un gateway condiviso o alla vostra uscita, e se esistono registri di sessione e per quanto tempo. Contate i proprietari nelle risposte, perché un contratto che nomina una sola parte per quattro compiti di solito ne lascia tre senza documentazione.
Una rotta predefinita ampia importata nel contesto di routing privato merita lo stesso esame, perché un’importazione è un accordo deliberato e non una comodità innocua. La sezione 11 della RFC 4364 passa in rassegna diverse disposizioni di accesso a internet per VPN BGP/MPLS e tratta lo scambio di rotte tra il contesto VPN e il contesto di inoltro predefinito del fornitore esattamente come quel tipo di accordo. Chiedete cosa impedisce al traffico pubblico di prendere per errore un cammino privato, e ottenete la risposta accanto alla politica delle rotte e non in una diapositiva.
Due casi di guasto da concordare prima della firma
Scrivete nel contratto due test: perdere l’uscita internet e perdere un collegamento privato. Per ciascuno, elencate le risorse interne, i servizi internet locali e i percorsi di gestione che devono continuare a funzionare. Elencate poi il percorso di riserva che deve restare bloccato, perché un percorso che aggira i controlli centrali è peggio di un’interruzione pulita. Date entrambi i test al fornitore e chiedete il risultato atteso per iscritto, compresi rilevamento e notifica.
Eseguite le stesse prove da un sito pilota e confrontatele con quella risposta scritta. Dove le due non concordano, il contratto descrive una rete diversa da quella che avete acquistato. Due comandi coprono i casi comuni: uno mostra il percorso che prende una destinazione pubblica, l’altro l’indirizzo che vede.
traceroute -n 203.0.113.10
curl -s https://example.net/ipLegate gli impegni di disponibilità al segmento che avete misurato, non al nome del servizio. Un circuito locale, un backbone del fornitore e un gateway condiviso portano obblighi separati e team di escalation separati. Le lettere L2VPN, L3VPN e MPLS descrivono un meccanismo di inoltro, non una garanzia da estremità a estremità.
Le prove battono gli aggettivi della proposta
Parole come ridondante, sicuro e resiliente descrivono un’intenzione e non un progetto. Chiedete invece l’elenco dei dispositivi, le posizioni di uscita, lo schema di traduzione e il percorso di notifica. Un fornitore che sa produrre questi quattro elementi ha un progetto; chi non sa farlo ha una diapositiva. Tenete le risposte nella documentazione del servizio e non in un filo di e-mail, e riesaminatele a ogni modifica del contratto.
Le disposizioni di uscita si spostano in silenzio mentre i fornitori consolidano i gateway, quindi uno schema di tre anni fa è un peso. Quando un partner segnala un indirizzo sorgente sconosciuto, dovreste poter dire in pochi minuti se viene dal vostro progetto o da una modifica che nessuno ha annunciato. Quella capacità, e non gli aggettivi, è ciò che sopravvive al primo guasto.