Où sort réellement la sortie internet de votre VPN géré
« Internet inclus » ne dit rien sur l’endroit où sort le trafic public, qui le filtre ou ce qui survit à une panne. Suivez le chemin, puis écrivez les deux cas de panne.
Vous ne pouvez pas dire qui filtre le trafic public d’une agence tant que la proposition ne montre pas par où ce trafic quitte le réseau du fournisseur. L’accès internet inclus dans un VPN géré est un second service, qui circule sur un chemin doté de ses propres passerelles, de sa propre traduction d’adresses et de sa propre file d’escalade. La plupart des contrats décrivent le côté privé en détail et laissent le côté public à une phrase. Les vérifications ci-dessous transforment cette phrase en un schéma que vous pouvez défendre.
Suivez une destination publique par site
Choisissez un hôte d’une agence et suivez une destination publique, en notant la dernière adresse qui appartient au fournisseur et la première qui appartient à internet. Le saut entre ces deux adresses est la sortie, et il se situe souvent loin du site qui a envoyé le paquet. Marquez l’équipement qui effectue la transition, car c’est lui qui porte le filtre décidant de ce qui sort. Répétez la trace depuis un second site et comparez les adresses de sortie, car deux agences identiques sur la facture peuvent sortir par des passerelles différentes dans des villes différentes.
Notez aussi l’adresse source que la destination voit réellement, car la traduction peut se produire à un saut que vous n’avez jamais dessiné. Écrivez les réponses observées à côté des réponses dessinées, et l’écart entre les deux est l’endroit d’où viendra le premier incident. Un ingénieur du fournisseur incapable de donner l’adresse de sortie d’un site donné vous a déjà dit quelque chose d’utile sur la conception.
Trois dispositions de sortie et ce que chacune concentre
Une sortie centrale que vous exploitez attire le trafic public vers une passerelle qui vous appartient, ce qui vous donne la politique de filtrage et les journaux tout en concentrant la charge de tous les sites sur un seul circuit. Une sortie exploitée par le fournisseur déplace la politique et les journaux au-delà de la frontière contractuelle, ce qui simplifie l’exploitation et vous retire la visibilité du même geste. Une sortie sur chaque site garde le trafic public local et multiplie le nombre de surfaces de politique qui doivent rester identiques.
| 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 |
Demandez laquelle des trois le fournisseur propose réellement avant de traiter la liste comme un menu, et demandez si un site peut passer de l’une à l’autre sans nouveau circuit. La réponse sur la migration sépare ce qui est contractuel de ce qui est purement technique. Notez aussi qui possède la traduction d’adresses source, car cela décide de ce qu’un partenaire doit inscrire sur sa liste d’autorisation. Les passerelles partagées signifient aussi une capacité partagée et, parfois, une réputation partagée, ce qui change la façon dont les partenaires traitent vos adresses. La capacité mérite sa propre question, car une passerelle partagée sert d’autres clients au même moment.
Le filtrage, la traduction et le chiffrement ont des propriétaires distincts
Une route établit l’accessibilité et ne dit rien de l’inspection, alors traitez les deux comme des questions différentes avec des propriétaires différents. Pour chaque route par défaut annoncée, nommez l’équipement qui filtre, celui qui authentifie, celui qui traduit et celui qui inspecte, puis nommez qui administre chacun. La séparation des routes chez le fournisseur ne dit pas où le chiffrement se termine, et un service privé peut terminer son tunnel à une frontière pendant que la sortie publique se termine à une autre. Demandez si la traduction a lieu à la périphérie du fournisseur, sur une passerelle partagée ou à votre propre sortie, et si des journaux de session existent et pendant combien de temps. Comptez les propriétaires dans les réponses, car un contrat qui nomme une seule partie pour quatre tâches en laisse généralement trois sans documentation.
Une route par défaut large importée dans le contexte de routage privé mérite le même examen, car un import est un accord délibéré et non une commodité inoffensive. La section 11 de la RFC 4364 parcourt plusieurs dispositions d’accès internet pour les VPN BGP/MPLS et traite l’échange de routes entre le contexte VPN et le contexte de transfert par défaut du fournisseur exactement comme ce type d’accord. Demandez ce qui empêche le trafic public de prendre par accident un chemin privé, et obtenez la réponse à côté de la politique de routage plutôt que dans une diapositive.
Deux cas de panne à convenir avant de signer
Inscrivez deux tests au contrat : perdre la sortie internet et perdre un attachement privé. Pour chacun, listez les ressources internes, les services internet locaux et les chemins de gestion qui doivent continuer de fonctionner. Listez ensuite le chemin de secours qui doit rester bloqué, car un chemin qui contourne les contrôles centraux est pire qu’une coupure nette. Donnez les deux tests au fournisseur et demandez leur résultat attendu par écrit, y compris la détection et la notification.
Exécutez les mêmes sondes depuis un site pilote et comparez-les à cette réponse écrite. Là où les deux divergent, le contrat décrit un autre réseau que celui que vous avez acheté. Deux commandes couvrent les cas courants : l’une montre le chemin que prend une destination publique, l’autre l’adresse qu’elle voit.
traceroute -n 203.0.113.10
curl -s https://example.net/ipAttachez les engagements de disponibilité au segment que vous avez mesuré, non au nom du service. Un circuit local, un backbone de fournisseur et une passerelle partagée portent des obligations distinctes et des équipes d’escalade distinctes. Les lettres L2VPN, L3VPN et MPLS décrivent un mécanisme de transfert, pas une garantie de bout en bout.
Les preuves battent les adjectifs de la proposition
Des mots comme redondant, sécurisé et résilient décrivent une intention et non une conception. Demandez plutôt la liste des équipements, les emplacements de sortie, le schéma de traduction et le chemin de notification. Un fournisseur capable de produire ces quatre éléments a une conception ; celui qui ne le peut pas a une diapositive. Gardez les réponses dans la documentation du service plutôt que dans un fil d’e-mails, et revoyez-les à chaque changement de contrat.
Les dispositions de sortie bougent discrètement à mesure que les fournisseurs consolident leurs passerelles, donc un schéma vieux de trois ans est une charge. Quand un partenaire signale une adresse source inconnue, vous devriez pouvoir dire en quelques minutes si elle vient de votre conception ou d’un changement que personne n’a annoncé. Cette capacité, et non les adjectifs, est ce qui survit à la première panne.