GCP HA VPN: BGP-Session hängt bei Waiting for peer, der Tausch der Adresspaare

Eine BGP-Session, die auf einem Cloud VPN-Tunnel nie den Zustand Established erreicht, ist meist kein Routing-Problem. Es ist ein Verdrahtungsproblem: Zwei Adressen, die sich gegenseitig spiegeln müssen, wurden in der falschen Reihenfolge eingetragen, oder das Paar des ersten Tunnels wurde für den zweiten wiederverwendet. Der Tunnel selbst kann völlig gesund sein, während die Session bei Waiting for peer steht, denn IPsec und BGP sind getrennte Verhandlungen zwischen denselben beiden Endpunkten. Entscheiden Sie, welche der beiden Seiten defekt ist, bevor Sie etwas neu aufbauen.

Eine Frage klärt die meisten Fälle: Sieht das Peer-Gerät die Adresse des Cloud Routers überhaupt?

Tunnel-Zustand und Session-Zustand sind verschiedene Prüfungen

IKE und ESP kommen zuerst. Steht der Tunnel nicht, spielt nichts darin eine Rolle, und die Diskussion über BGP-Adressen ist verfrüht. Lesen Sie den Status und den detaillierten Status des Tunnels und danach den BGP-Peer-Status des Routers für genau diesen Tunnel.

Ein Tunnel, der steht, während sein BGP-Peer unten ist, grenzt den Fehler auf die Session ein: Peer-Adresse, ASN oder TCP 179, das auf der inneren Adresse ankommt. Ein Tunnel, der steht, eine Session, die steht, und immer noch keine Routen in der VPC ist ein dritter Fall. Adressen zu ändern hilft dort nicht, denn die Session funktioniert bereits und das Präfix wird schlicht nicht angekündigt oder nicht bevorzugt. Diese drei Fälle auseinanderzuhalten ist der größte Teil der Arbeit.

Jeder Tunnel braucht sein eigenes /30, mit beiden Enden ausgefüllt

Jeder HA VPN-Tunnel bekommt ein link-local /30 aus 169.254.0.0/16, wobei eine Adresse auf der Schnittstelle des Cloud Routers und die andere bei Ihrem Peer liegt. Das Peer-Feld muss das entfernte Ende benennen, niemals die eigene Adresse des Routers.

Zwei Tunnel bedeuten zwei Schnittstellen auf dem Cloud Router, jede mit einem anderen /30. Das Paar von Tunnel 0 auf Tunnel 1 wiederzuverwenden ist der Fehler, der in einer Übersichtstabelle ordentlich aussieht und im OPEN-Paket stirbt.

Lesen Sie das Paar aus der Router-Ressource und nicht aus der Konsolenübersicht. Die Übersicht listet die Peer-Adresse in einer Spalte, die man leicht falsch liest, und das ipRange der Schnittstelle plus die peerIpAddress des Peers müssen entgegengesetzte Enden eines /30 beschreiben.

Der Tausch passiert meistens während eines Neuaufbaus

Beim Neuaufbau eines Tunnels werden Paare vertauscht. Die Peer-Adresse des alten Tunnels wird in das Schnittstellenfeld des neuen kopiert, oder die neue Session zeigt auf den Peer der vorherigen. So oder so sendet der Cloud Router OPEN-Pakete an eine Adresse, die nun er selbst ist, oder an eine Adresse ohne Tunnel dahinter.

Schreiben Sie die Paare auf, bevor Sie die Konsole öffnen: Tunnelname, Schnittstelle, Router-Adresse, Peer-Adresse, Peer-ASN. Legen Sie dann beide Tunnel in einem Durchgang an, damit der zweite nicht aus den Resten des ersten gefüllt wird.

Drei weitere Gründe, warum eine Session wartet

Die Peer-ASN ist der erste: Jede Seite muss mit der ASN der anderen Seite konfiguriert sein, und eine Abweichung erreicht den Peer, etabliert sich aber nie. Der zweite ist die Firewall des Peers selbst, die TCP 179 auf der Tunnel-Schnittstelle zulassen muss; eine IKE- oder ESP-Regel deckt das nicht ab. Der dritte ist ein Peer, der von einer anderen Quelladresse antwortet als der, die als sein Nachbar konfiguriert ist.

Das eigene Log des Peers ist der entscheidende Hinweis. Wenn seine BGP-Übersicht keinen Nachbarn für diese Adresse listet, kommen keine Pakete an, und das Paar oder der Pfad ist falsch. Steht der Nachbar auf Active oder Connect, kommen Pakete an, und die Session-Parameter passen nicht zusammen.

Prüfen Sie in der Reihenfolge, in der die Pakete wandern

Arbeiten Sie sich nach außen: Tunnel-Status, dann BGP-Peer-Status des Routers, dann die BGP-Übersicht des Peers, dann die Routen. Sind die ersten beiden gesund, hören Sie auf, an der Cloud VPN-Seite zu ändern, und arbeiten Sie am Peer-Gerät. Meldet der Router den Peer als unten und Ihr Gerät hat keinen Nachbarn, ist das Paar falsch oder der BGP-Port wird gefiltert. Ein Paketmitschnitt auf der Tunnel-Schnittstelle des Peers klärt es mit einem Blick, denn OPEN-Pakete kommen dort entweder an oder nie.

gcloud compute routers get-status ROUTER --region=REGION zeigt den Peer-Zustand neben der Adresse, die er verwendet, und das ist genau das Paar, das Sie vergleichen müssen.

Sobald die Session steht, prüfen Sie, ob das gelernte Präfix in der Routentabelle der VPC erscheint und ob je ein Host auf beiden Seiten antwortet. Halten Sie dann die endgültigen Paare neben den Tunnelnamen fest, damit der nächste Neuaufbau von einer bewährten Tabelle ausgeht und nicht von der Konsolenübersicht.