Sesja BGP, która nigdy nie osiąga Established na tunelu Cloud VPN, zwykle nie jest problemem routingu. To problem okablowania: dwa adresy, które muszą się wzajemnie odbijać, wpisano w złej kolejności albo para pierwszego tunelu została użyta ponownie na drugim. Sam tunel może być całkowicie zdrowy, podczas gdy sesja stoi na Waiting for peer, ponieważ IPsec i BGP to odrębne negocjacje między tymi samymi dwoma punktami końcowymi. Zdecyduj, który z tych dwóch jest zepsuty, zanim cokolwiek odbudujesz.

Jedno pytanie rozstrzyga większość przypadków: czy urządzenie peera w ogóle widzi adres Cloud Routera?

Stan tunelu i stan sesji to dwie różne kontrole

Najpierw IKE i ESP. Jeśli tunel nie jest zestawiony, nic w jego wnętrzu nie ma znaczenia, a dyskusja o adresie BGP jest przedwczesna. Odczytaj stan i stan szczegółowy tunelu, a następnie stan peera BGP routera dla tego samego tunelu.

Tunel, który działa, gdy jego peer BGP jest wyłączony, zawęża usterkę do sesji: adres peera, ASN albo TCP 179 docierający na adres wewnętrzny. Tunel działa, sesja działa i wciąż brak tras w VPC to trzeci przypadek. Zmiana adresów tam nie pomoże, ponieważ sesja już działa, a prefiks po prostu nie jest ogłaszany albo nie jest preferowany. Rozdzielenie tych trzech przypadków to większość pracy.

Każdy tunel potrzebuje własnego /30 z wypełnionymi oboma końcami

Każdy tunel HA VPN dostaje link-local /30 z 169.254.0.0/16, jeden adres na interfejsie Cloud Routera, drugi na twoim peerze. Pole peera musi wskazywać drugi koniec, nigdy własny adres routera.

Dwa tunele to dwa interfejsy na Cloud Routerze, każdy z innym /30. Ponowne użycie pary tunelu 0 na tunelu 1 to błąd, który wygląda schludnie w tabeli zbiorczej i ginie w pakiecie OPEN.

TunnelRouter interfacePeer addressWhat a swap produces
tunnel 0169.254.1.1/30169.254.1.2OPEN sent to itself or to nothing; session waits
tunnel 1169.254.1.5/30169.254.1.6same failure on the second session
bothone pair reusedone address reusedone session up, the other never leaves waiting

Czytaj parę z zasobu routera, a nie z podsumowania w konsoli. Podsumowanie podaje adres peera w kolumnie, którą łatwo odczytać błędnie, a ipRange interfejsu plus peerIpAddress peera muszą opisywać przeciwne końce jednego /30.

Zamiana zdarza się zwykle podczas odbudowy

To właśnie przy odbudowie tunelu pary się krzyżują. Adres peera starego tunelu trafia do pola interfejsu nowego albo nowa sesja zostaje skierowana na peera poprzedniej sesji. Tak czy inaczej Cloud Router wysyła pakiety OPEN na adres, który jest teraz nim samym, albo na adres bez tunelu za nim.

Zapisz pary przed otwarciem konsoli: nazwa tunelu, interfejs, adres routera, adres peera, ASN peera. Potem utwórz oba tunele w jednym przejściu, żeby drugi nie został wypełniony resztkami pierwszego.

Trzy inne powody, dla których sesja czeka

ASN peera jest pierwszy: każda strona musi być skonfigurowana z ASN drugiej, a niezgodność dociera do peera, ale nigdy się nie zestawia. Drugi to własna zapora peera, która musi zezwalać na TCP 179 na interfejsie tunelu; reguła IKE albo ESP tego nie obejmuje. Trzeci to peer, który odpowiada z innego adresu źródłowego niż ten skonfigurowany jako jego sąsiad.

Decydujący jest własny log peera. Jeśli jego podsumowanie BGP nie wymienia sąsiada dla tego adresu, pakiety nie docierają, a para albo ścieżka są błędne. Jeśli sąsiad stoi w Active albo Connect, pakiety docierają, a parametry sesji się nie zgadzają.

Sprawdzaj w kolejności, w jakiej wędrują pakiety

Pracuj na zewnątrz: stan tunelu, potem stan peera BGP routera, potem podsumowanie BGP peera, potem trasy. Jeśli pierwsze dwa są zdrowe, przestań edytować stronę Cloud VPN i pracuj na urządzeniu peera. Jeśli router zgłasza peera jako wyłączonego, a twoje urządzenie nie ma żadnego sąsiada, para jest błędna albo port BGP jest filtrowany. Przechwycenie pakietów na interfejsie tunelu peera rozstrzyga to jednym spojrzeniem, bo pakiety OPEN albo tam docierają, albo nigdy.

gcloud compute routers get-status ROUTER --region=REGION wypisuje stan peera obok adresu, którego używa, i to jest dokładnie ta para, którą trzeba porównać.

Gdy sesja się zestawi, potwierdź, że nauczony prefiks pojawia się w tabeli tras VPC i że jeden host po każdej stronie odpowiada. Potem zapisz ostateczne pary obok nazw tuneli, aby następna odbudowa zaczęła się od sprawdzonej tabeli, a nie od podsumowania w konsoli.

Powiązane artykuły