Extension du site VPN : suivez la route de retour au-delà de la passerelle

Le trafic d’une agence aboutit sur une passerelle dont le LAN ne contient pas l’application à laquelle vous deviez accéder. Le serveur se trouve dans un second centre de données, au-delà d’une liaison interne que le VPN n’a jamais configurée. Ajouter un autre préfixe à la passerelle proche ne fait rien pour ce cas, car la passerelle distante est un point de chiffrement et non le dernier routeur. Le chemin a besoin d’une route vers l’avant, d’une admission à la frontière de sécurité distante et d’une décision de retour dans le réseau de la destination elle-même.

La passerelle distante est un point de chiffrement

L’IPsec de passerelle à passerelle protège le trafic entre deux équipements de sécurité, et les adresses internes traversent ce segment chiffrées. Au-delà de la passerelle distante, le routage ordinaire prend le relais, y compris toute politique qui existe entre centres de données. Le segment protégé couvre donc une partie du trajet et non le reste. Supposer le contraire est la façon dont une conception finit avec un tunnel sain et une application injoignable.

Tracez le chemin en trois tronçons : agence vers passerelle proche, proche vers distante, distante vers l’application. Chaque tronçon a son propre responsable et son propre mode de défaillance.

Lisez les deux sens de la politique de tunnel

Une politique de tunnel s’écrit généralement du point de vue du côté local, et c’est de cette habitude que viennent les configurations partielles. Les deux pairs doivent lister la source de l’agence et la destination telles qu’elles apparaîtront dans le tunnel, y compris toute traduction que la conception prévoit. Mettre à jour seulement l’extrémité proche produit un décalage de phase deux qui ressemble à une panne de routage. Comparez les deux jeux de politiques avant de toucher à une route.

Écrivez la source et la destination comme des adresses plutôt que comme des noms de site. L’ambiguïté ici resurgit plus tard sous forme d’asymétrie déroutante.

Ajoutez la route vers l’avant et confirmez l’admission

La passerelle distante a besoin d’une route vers le sous-réseau de l’application, et chaque routeur entre elles doit admettre la source de l’agence. Vérifiez ce que la passerelle distante possède réellement plutôt que ce que le schéma affirme.

ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10

La première commande indique l’interface de sortie et le prochain saut que la passerelle distante choisirait pour cette source, une question à laquelle une table de routage ordinaire ne peut pas répondre. La trace montre où les paquets s’arrêtent, et une coupure après la passerelle distante désigne le transit interne plutôt que le tunnel. Quand la route existe et que le trafic disparaît encore, capturez sur la passerelle distante et lisez l’adresse source qui arrive, car une adresse inattendue signifie qu’une traduction se produit quelque part sans planification. Toutes les adresses ici sont des exemples, alors remplacez par les vrais sous-réseaux de l’agence, du transit et de l’application.

Testez depuis l’agence, puis retestez l’ancien chemin

L’acceptation exige une source réelle plutôt qu’une sonde depuis la passerelle distante. Exécutez la vérification depuis un hôte de l’agence et gardez les destinations qui fonctionnaient déjà dans le même test.

curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1

Une réponse de l’application prouve ensemble le chemin aller et le chemin retour, tandis que le ping vers l’ancienne destination prouve que le changement n’a pas cassé ce qui fonctionnait déjà. Relevez l’adresse source que l’application journalise, car ses règles d’accès et toute route de retour doivent correspondre à cette valeur. Là où l’agence traduit avant le tunnel, l’adresse de la politique et l’adresse que voit l’application diffèrent par conception, alors notez les deux. Répétez le test après un renouvellement de clé ou un changement de routage, car ces chemins ont tendance à être validés une fois puis oubliés.

Attribuez un responsable à chacun des trois segments et à la route de retour dans le réseau de destination. Un chemin à quatre responsables échoue dans les interstices entre eux.