VPN-site-uitbreiding: volg de retourroute voorbij de gateway

Verkeer van een vestiging eindigt op een gateway waarvan het LAN de applicatie niet bevat die u moest bereiken. De server staat in een tweede datacenter, achter een interne verbinding die de VPN nooit heeft geconfigureerd. Nog een prefix toevoegen aan de nabije gateway doet niets voor dat geval, omdat de verre gateway een versleutelingspunt is en niet de laatste router. Het pad heeft een route verder nodig, een toelating bij de verre beveiligingsgrens en een terugbeslissing in het eigen netwerk van de bestemming.

De verre gateway is een versleutelingspunt

IPsec tussen gateways beschermt verkeer tussen twee beveiligingsapparaten, en de interne adressen reizen versleuteld over dat segment. Voorbij de verre gateway neemt gewone routering het over, inclusief elk beleid dat tussen datacenters bestaat. Het beschermde segment dekt dus een deel van de reis en niet de rest. Het tegenovergestelde aannemen is hoe een ontwerp eindigt met een gezonde tunnel en een onbereikbare applicatie.

Teken het pad in drie stukken: vestiging naar nabije gateway, nabije naar verre gateway, verre gateway naar de applicatie. Elk stuk heeft zijn eigen eigenaar en zijn eigen faalmodus.

Lees beide richtingen van het tunnelbeleid

Een tunnelbeleid wordt meestal vanuit het perspectief van de lokale kant geschreven, en juist die gewoonte is de bron van gedeeltelijke configuraties. Beide peers moeten de bron van de vestiging en de bestemming vermelden zoals ze in de tunnel verschijnen, inclusief elke vertaling die het ontwerp beoogt. Alleen het nabije uiteinde bijwerken levert een fase-twee-mismatch op die op een routeringsfout lijkt. Vergelijk de twee beleidssets voordat u een route aanraakt.

Schrijf bron en bestemming als adressen in plaats van sitenamen. Dubbelzinnigheid hier duikt later weer op als een raadselachtige asymmetrie.

Voeg de route verder toe en bevestig de toelating

De verre gateway heeft een route naar het subnet van de applicatie nodig, en elke router daartussen moet de bron van de vestiging toelaten. Controleer wat de verre gateway werkelijk heeft in plaats van wat het diagram beweert.

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

De eerste opdracht meldt de uitgaande interface en de volgende hop die de verre gateway voor die bron zou kiezen, een vraag die een gewone routeringstabel niet kan beantwoorden. De trace laat zien waar pakketten stoppen, en een breuk na de verre gateway wijst op intern transport en niet op de tunnel. Als de route bestaat en het verkeer verdwijnt toch, leg dan vast op de verre gateway en lees het binnenkomende bronadres, want een onverwacht adres betekent dat er ergens ongepland wordt vertaald. Alle adressen hier zijn plaatsaanduidingen, dus vervang ze door de echte subnetten van vestiging, transport en applicatie.

Test vanaf de vestiging en test daarna het oude pad opnieuw

Acceptatie vereist een echte bron in plaats van een sonde vanaf de verre gateway. Voer de controle uit vanaf een host in de vestiging en houd de eerder werkende bestemmingen in dezelfde test.

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

Een antwoord van de applicatie bewijst het pad heen en de terugweg samen, terwijl de ping naar de oude bestemming bewijst dat de wijziging niet heeft gebroken wat al werkte. Leg het bronadres vast dat de applicatie logt, want de toegangsregels en elke retourroute moeten met die waarde overeenkomen. Waar de vestiging vóór de tunnel vertaalt, verschillen het beleidsadres en het adres dat de applicatie ziet per ontwerp, dus noteer beide. Herhaal de test na een sleutelvernieuwing of een routeringswijziging, want deze paden worden meestal één keer gevalideerd en daarna vergeten.

Wijs een eigenaar toe aan elk van de drie segmenten en aan de retourroute binnen het bestemmingsnetwerk. Een pad met vier eigenaren faalt in de gaten daartussen.