AWS Site-to-Site VPN: außen, innen und das LAN-Präfix

Die meisten Fehler bei AWS Site-to-Site VPN sind Adressfehler, und sie entstehen, bevor sich ein einziges Paket bewegt. Die Außenadressen des Tunnels erreichen die IPsec-Peers, die Innenadressen bilden die Routing-Verbindung zwischen ihnen, und die geschützten Präfixe sind der Zweck dieser Verbindung. Kopiert man eine Rolle in die andere, kommt der Tunnel hoch, während nichts geroutet wird. Hier ist die Reihenfolge Lesen-Prüfen-Konfigurieren, die ich auf einem BGP-Customer-Gateway verwende, mit den Werten aus der heruntergeladenen Gerätekonfiguration statt aus dem Gedächtnis.

Drei Adressrollen, ein Tunnel

Die Außenadressen sind öffentlich und gehören den IPsec-Peers: eine pro Tunnel auf der AWS-Seite und die erreichbare Identität des Customer Gateways auf Ihrer Seite, angepasst an die NAT-Konstellation, die Sie tatsächlich haben. Die Innenadressen sind privat und gehören der logischen Verbindung, die AWS als /30 aus 169.254.0.0/16 dokumentiert. Die geschützten Präfixe sind die VPC-, On-Premises- oder Transitnetze, die Sie über diese Verbindung routen und annoncieren.

Ein LAN-Präfix als Adresse des Tunnel-Interfaces zu vergeben ist die klassische Variante dieses Fehlers. Das Interface sieht konfiguriert aus, das LAN wird nicht annonciert, und die Gegenseite hat keine Route dafür. Der Tunnel kann sogar seinen eigenen Innen-Ping bestehen, während jeder Anwendungsname in einen Timeout läuft. Die Referenz zu den Tunneloptionen listet die Einschränkungen für das innere CIDR auf, einschließlich des Adressbereichs, aus dem es stammen muss.

Lesen Sie die Werte aus der heruntergeladenen Konfiguration

Laden Sie die Konfiguration für Ihr konkretes Gerätemodell aus der Verbindung herunter und behandeln Sie deren Adresstabelle als Quelle der Wahrheit. Die Konsole zeigt dieselben Werte pro Tunnel: Außen-IP, inneres CIDR und die BGP-Peer-Adresse auf der AWS-Seite. Die beiden Tunnel sind getrennte Objekte mit getrennten Außenendpunkten und getrennten inneren /30, obwohl beide dieselben geschützten Netze tragen.

aws ec2 describe-vpn-connections --vpn-connection-ids vpn-0123456789abcdef0 \
  --query 'VpnConnections[0].Options.TunnelOptions[].[OutsideIpAddress,TunnelInsideCidr]'
aws ec2 describe-customer-gateways --customer-gateway-ids cgw-0123456789abcdef0 \
  --query 'CustomerGateways[0].[IpAddress,BgpAsn]'

Wenn die heruntergeladene Datei und die Live-Konsole nicht übereinstimmen, ist die Datei veraltet. Laden Sie neu herunter, statt Adressen von Hand zu bearbeiten, denn eine Abweichung zwischen dem inneren Paar und dem konfigurierten Nachbarn des Peers ist ein stiller BGP-Fehler.

Bauen Sie die Verbindung mit der richtigen Adresse darauf

Auf einem Linux-Gateway ist der Tunnel ein VTI- oder XFRM-Interface, und das innere /30 liegt auf diesem Interface. Zwei Tunnel bedeuten zwei Interfaces und zwei BGP-Nachbarn, einen pro AWS-Endpunkt. Die Konvention, die AWS in der heruntergeladenen Gerätekonfiguration ausgibt, setzt das Virtual Private Gateway auf die erste Adresse jedes inneren /30 und Ihr Customer Gateway auf die zweite, Sie nehmen also die höhere Adresse und peeren mit der niedrigeren. Nichts hier braucht eine LAN-Adresse.

ip tunnel add tun0 mode vti local 203.0.113.10 remote 18.230.1.1 key 42
ip addr add 169.254.10.2/30 dev tun0
ip link set tun0 up mtu 1400
ip tunnel add tun1 mode vti local 203.0.113.10 remote 18.230.2.1 key 43
ip addr add 169.254.10.6/30 dev tun1
ip link set tun1 up mtu 1400

Wenn die Datei für Ihr Gerätemodell die umgekehrte Paarung ausgibt, verwenden Sie deren Zahlen und halten Sie die Regel ein: Die Adresse am Interface gehört Ihnen, die Peer-Adresse gehört AWS. Andersherum entsteht ein Tunnel, der nie Established erreicht, weil der konfigurierte Nachbar die Adresse ist, die Ihr eigenes Interface bereits hält.

Halten Sie die Markierung und den VTI-Key mit dem abgestimmt, was der IKE-Daemon verwendet, um eine Child-SA an das Interface zu binden, sonst kommt Verkehr am Tunnel an, ohne dass ein Interface zum Landen da ist. Prüfen Sie die MTU gegen den Pfad und gegen die eigenen Einstellungen des IKE-Daemons, statt eine Zahl von einer anderen Site zu kopieren.

Prüfen Sie BGP, bevor Sie Routen prüfen

Dass IPsec hochkommt, beweist, dass sich die Peers auf eine Security Association einig sind, und sonst nichts. Die BGP-Session ist eine separate Verhandlung über die innere Verbindung, lesen Sie also den Nachbarzustand und die Präfixzähler und vergleichen Sie sie mit dem, was Sie annoncieren wollten.

ip -s addr show dev tun0
vtysh -c 'show bgp summary'
vtysh -c 'show bgp neighbors 169.254.10.1'
vtysh -c 'show ip bgp neighbors 169.254.10.1 advertised-routes'

Zustand Established mit null empfangenen Präfixen ist ein Policy- oder Annoncierungsproblem, kein Tunnelproblem. Wiederholen Sie die ganze Prüfung am zweiten Tunnel; ein funktionierender erster Tunnel sagt Ihnen, dass die Adressen plausibel sind, nicht dass der zweite Tunnel überhaupt konfiguriert wurde.

Folgen Sie einem gerouteten Paket und hören Sie dann auf

Sobald die Session die Präfixe trägt, testen Sie die Route in beide Richtungen vom Gateway aus: Quelladresse, nächster Hop und die Sicherheitsrichtlinie, die den Verkehr erlaubt. Eine BGP-Session kann stehen, während das konkrete Präfix, das Ihre Anwendung braucht, gefiltert, weggesummarisiert oder auf das falsche Interface gezeigt wird.

Reachability Analyzer ist das Werkzeug auf der AWS-Seite, das eine Quelle, ein Ziel und einen Pfad nimmt und berichtet, welche Komponente in einer unterstützten Konfiguration ihn blockiert hat. Nutzen Sie es, um den Pfad von der VPC zur Adresse Ihres Customer Gateways zu testen, nicht von einem Anwendungshost aus. Es analysiert Konfiguration und sendet kein Paket durch eine lokale Firewall, halten Sie sein Urteil also getrennt von Ihren eigenen Interface-Zählern und Paketmitschnitten.

Schreiben Sie das Außenpaar, das innere /30 und die annoncierten Präfixe für jeden Tunnel in eine Tabelle. Diese Tabelle macht die nächste Änderung überprüfbar.