Adresy BGP Cloud VPN należą do wnętrza tunelu, a nie do karty sieciowej

Otwórz stronę Cloud Routera dla VPN i patrzy na ciebie sesja BGP z adresem w 169.254.0.0/16. Naturalną reakcją jest umieszczenie tego adresu gdzieś na VM i czekanie, aż sesja się podniesie. Ta reakcja jest błędna w konkretny sposób: para należy do łącza logicznego, które tworzy tunel IPsec, a nie do zwykłego interfejsu sieciowego maszyny. Nic, co dodasz do karty sieciowej, nie sprawi, że tunel będzie przenosił BGP.

Prześledź parę w dół stosu, zamiast dodawać ją do hosta.

Zacznij tam, gdzie konsola pokazuje parę

Strona sesji wymienia adres BGP Cloud Routera i adres peera, oba link-local dla HA VPN IPv4. Obok nich są zewnętrzne adresy bram, które kończą tunele. To różne obiekty: para link-local żyje wewnątrz, a adresy bram żyją na zewnątrz i muszą być trasowalne, zanim cokolwiek innego zacznie działać.

Zapisz wszystkie trzy, zanim otworzysz plik konfiguracyjny, bo ich pomieszanie to cały tryb awarii.

Zejdź do tunelu, który ją przenosi

Para link-local ma znaczenie dopiero wtedy, gdy między dwiema bramami istnieje asocjacja bezpieczeństwa IPsec. Po stronie Google tunele HA VPN tworzą ją na dwóch interfejsach; po twojej stronie to jest to, co wynegocjował peer. Najpierw sprawdź asocjację danych za pomocą swanctl --list-sas i zanotuj, który tunel jest podniesiony na którym interfejsie, bo zdrowa sesja BGP nad martwym tunelem jest niemożliwa, a martwy tunel z pełną nadziei konfiguracją jest codziennością.

Pakiet BGP to wewnętrzny ruch IP. Zewnętrzna sieć nigdy go nie widzi, więc żaden przełącznik nie potrzebuje obu adresów w jednym VLAN-ie.

Teraz skonfiguruj peera Linux, aby pasował

Wybierz obsługiwany projekt tunelu i pozwól mu zdecydować o adresach wewnętrznych. W przypadku interfejsu opartego na trasowaniu wpis trasowania i wynegocjowane selektory ruchu muszą się zgadzać, bo sama nazwa interfejsu niczego nie pozwala. Skieruj BIRD na wewnętrzny adres lokalny i wewnętrzny adres Cloud Routera, ustaw numery AS ze strony sesji i zezwól na TCP 179 w chronionej ścieżce. Trzymaj trasę do odległego adresu zewnętrznego na fizycznym uplinku, aby tunel nie przechwycił własnego transportu.

Tunel, który sam się trasuje, jest pętlą z uściskiem dłoni i przez godzinę będzie wyglądał jak problem z zaporą.

Sprawdzaj każdy etap po kolei, nie wszystko naraz

Przejdź etapy: asocjacja bezpieczeństwa podniesiona, wewnętrzny peer osiągalny z adresu tunelu, sesja BGP nawiązana, prefiksy zaakceptowane, a potem prefiks obciążenia faktycznie używany. birdc show protocols odpowiada na trzecie pytanie i na nic innego, dlatego ludzie zbyt wcześnie ogłaszają zwycięstwo.

Nawiązany sąsiad nie obiecuje, że obie strony ogłosiły potrzebne ci prefiksy ani że te trasy zostały zainstalowane jako preferowane.

Jeśli sesja jest nawiązana, a ruch nadal idzie złą drogą, porównaj ogłoszone prefiksy z tym, co robi z nimi tablica trasowania. Bardziej szczegółowa trasa gdzie indziej albo preferencja dla innej drogi daje ci działającą sesję BGP i żadnego użytecznego przekazywania.

Zatrzymaj się, zanim zastosujesz to do Router Appliance

Network Connectivity Center Router Appliance to inny model podłączenia. Jego peery Cloud Routera używają adresów wewnętrznych z układu VPC i podsieci, a nie pary link-local HA VPN. Jeśli prawdziwym celem jest BGP z VM trasującą, postępuj zgodnie z wymaganiami interfejsu tego produktu, zamiast kopiować sesję link-local.

Zakres link-local wciąż znaczy to, co mówi. Tunel logiczny dostarcza to sąsiedztwo i nie daje licencji na trasowanie dowolnych celów link-local przez VPC.