AWS Site-to-Site VPN: zewnętrzny, wewnętrzny i prefiks LAN

Trzy role adresów mylą się na jednym AWS VPN: zewnętrzni partnerzy, wewnętrzne łącze /30 i chronione prefiksy LAN. Przeczytaj je z pobranej konfiguracji.

Większość błędów w AWS Site-to-Site VPN to błędy adresów, i popełnia się je, zanim ruszy choćby jeden pakiet. Zewnętrzne adresy tunelu docierają do partnerów IPsec, wewnętrzne tworzą łącze routingu między nimi, a chronione prefiksy to cel tego łącza. Skopiuj jedną rolę w drugą, a tunel wstanie, choć nic się nie routuje. Oto sekwencja czytaj-sprawdź-skonfiguruj, której używam na bramie klienta BGP, z wartościami wziętymi z pobranej konfiguracji urządzenia, a nie z pamięci.

Trzy role adresów, jeden tunel

Zewnętrzne adresy są publiczne i należą do partnerów IPsec: jeden na tunel po stronie AWS, a po Twojej stronie osiągalna tożsamość bramy klienta, dopasowana do tego układu NAT, który naprawdę masz. Wewnętrzne adresy są prywatne i należą do łącza logicznego, które AWS dokumentuje jako /30 wzięty z 169.254.0.0/16. Chronione prefiksy to sieci VPC, lokalne lub tranzytowe, które routujesz i ogłaszasz przez to łącze.

Przydzielenie prefiksu LAN jako adresu interfejsu tunelu to klasyczna wersja tego błędu. Interfejs wygląda na skonfigurowany, LAN nie jest ogłaszany, a druga strona nie ma do niego trasy. Tunel może nawet przejść własny wewnętrzny ping, podczas gdy każda nazwa aplikacji kończy się przekroczeniem czasu. Dokumentacja opcji tunelu wymienia ograniczenia wewnętrznego CIDR, w tym zakres adresów, z którego musi pochodzić.

Czytaj wartości z pobranej konfiguracji

Pobierz konfigurację dla swojego konkretnego modelu urządzenia z połączenia, a następnie traktuj jej tabelę adresów jako źródło prawdy. Konsola pokazuje te same wartości dla każdego tunelu: zewnętrzny IP, wewnętrzny CIDR i adres partnera BGP po stronie AWS. Oba tunele to osobne obiekty z osobnymi zewnętrznymi punktami końcowymi i osobnymi wewnętrznymi /30, choć oba niosą te same chronione sieci.

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]'

Jeśli pobrany plik i konsola na żywo się nie zgadzają, plik jest nieaktualny. Pobierz go ponownie, zamiast edytować adresy ręcznie, bo niezgodność między parą wewnętrzną a skonfigurowanym sąsiadem partnera to cicha awaria BGP.

Zbuduj łącze z właściwym adresem

Na bramie Linux tunel to interfejs VTI lub XFRM, a wewnętrzny /30 trafia na ten interfejs. Dwa tunele oznaczają dwa interfejsy i dwóch sąsiadów BGP, po jednym na punkt końcowy AWS. Konwencja, którą AWS drukuje w pobranej konfiguracji urządzenia, stawia wirtualną bramę prywatną na pierwszym adresie każdego wewnętrznego /30, a Twoją bramę klienta na drugim, więc bierzesz wyższy adres i peerujesz z niższym. Nic tutaj nie potrzebuje adresu LAN.

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

Jeśli plik dla Twojego modelu urządzenia drukuje odwrotną parę, użyj jego liczb i trzymaj się reguły: adres na interfejsie jest Twój, adres partnera należy do AWS. Zrobienie tego odwrotnie daje tunel, który nigdy nie osiąga Established, bo skonfigurowany sąsiad to adres, który ma już Twój własny interfejs.

Trzymaj znacznik i klucz VTI zgodne z tym, czego demon IKE używa do wiązania podrzędnej SA z interfejsem, inaczej ruch przychodzi na tunel bez interfejsu, na którym mógłby wylądować. Sprawdzaj MTU względem ścieżki i względem własnych ustawień demona IKE, zamiast kopiować liczbę z innej witryny.

Sprawdź BGP, zanim sprawdzisz trasy

To, że IPsec wstaje, dowodzi, że partnerzy zgadzają się co do asocjacji bezpieczeństwa, i niczego więcej. Sesja BGP to osobne negocjacje przez łącze wewnętrzne, więc czytaj stan sąsiada i liczniki prefiksów, a potem porównaj je z tym, co zamierzałeś ogłaszać.

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'

Stan Established z zerem odebranych prefiksów to problem polityki lub ogłaszania, nie tunelu. Powtórz całe sprawdzenie na drugim tunelu; działający pierwszy tunel mówi, że adresy są wiarygodne, a nie że drugi tunel w ogóle skonfigurowano.

Śledź routowany pakiet, a potem się zatrzymaj

Gdy sesja niesie prefiksy, przetestuj trasę w obu kierunkach od bramy: adres źródłowy, następny skok i politykę bezpieczeństwa, która dopuszcza ruch. Sesja BGP może być podniesiona, podczas gdy konkretny prefiks potrzebny Twojej aplikacji jest filtrowany, agregowany albo wskazuje zły interfejs.

Reachability Analyzer to narzędzie po stronie AWS, które bierze źródło, cel i ścieżkę i raportuje, który komponent w obsługiwanej konfiguracji ją zablokował. Używaj go do testowania ścieżki z VPC do adresu bramy klienta, a nie z hosta aplikacji. Analizuje konfigurację i nie wysyła pakietu przez lokalną zaporę, więc trzymaj jego werdykt osobno od własnych liczników interfejsu i przechwyceń pakietów.

Zapisz parę zewnętrzną, wewnętrzny /30 i ogłaszane prefiksy dla każdego tunelu w jednej tabeli. To ta tabela czyni następną zmianę możliwą do przejrzenia.

Powiązane artykuły