Sprawdzenie źródła/celu to jedna brama, nie cała ścieżka VPN

VPN kończy się na instancji EC2, można dotrzeć do adresu tunelu tej instancji, a ruch, który miał przez nią przejść do innego prywatnego hosta, znika. To dwa różne testy, a ich mieszanie marnuje godziny. Pierwszy pyta, czy można dotrzeć do instancji; drugi wymaga, by przekazywała ruch do celu, który nie jest jej własny, co wymaga przekazywania w Linuksie, polityki zapory, trasy po drugiej stronie i uprawnienia na poziomie AWS, które nie ma nic wspólnego z systemem operacyjnym gościa. Nic w konsoli nie zwraca uwagi na tę różnicę. Objaw wygląda jak usterka routingu i zwykle nią nie jest.

Rozdziel oba testy, zanim cokolwiek zmienisz

Dotarcie do bramy dowodzi tunelu, trasy do jej adresu i grupy zabezpieczeń, która zezwala na wymianę. Przekazywanie dla innego hosta nie dowodzi niczego z tego: używa innego adresu źródłowego, innego celu i instancji w roli, dla której niekoniecznie została zbudowana. Zapisz oba testy osobno i zanotuj, który zawodzi, bo poprawka dla każdego z nich jest w innej konsoli. Instancja bramy zbudowana tylko do kończenia tuneli nie ma powodu przekazywać czegokolwiek innego, a jej wartości domyślne to odzwierciedlają. Dlatego drugi test wymaga własnej konfiguracji, a nie drobnej korekty pierwszego.

Ping, który działa do bramy, i ping, który zawodzi do hosta za nią, nie jest problemem okresowym. To oczekiwane zachowanie instancji, której nie powiedziano, że może przekazywać.

Zapisz ścieżkę, zanim dotkniesz ustawienia

Zanotuj prefiks klienta, instancję lub interfejs sieciowy przekazywania, docelową podsieć i trasę powrotną. Wpis w tabeli tras VPC wskazujący na instancję nie konfiguruje systemu operacyjnego instancji do przekazywania, a jądro gościa z włączonym przekazywaniem nie tworzy trasy VPC. Oba końce tej relacji muszą istnieć, a są one edytowane w różnych miejscach przez osoby o różnym dostępie.

Następnie sprawdź ustawienie kontroli źródła/celu na rzeczywistym komponencie przekazywania, a nie na każdej instancji w VPC. AWS dokumentuje, dlaczego instancja przekazująca ruch za innych musi mieć tę kontrolę wyłączoną, a także dlaczego ustawienie jest decyzją dla każdej instancji, a nie wartością domyślną dla całego VPC.

Cztery granice, a kontrola jest tylko jedną z nich

Traktuj ścieżkę jako cztery pytania i odpowiadaj na nie po kolei. Pierwsza nieudana odpowiedź wskazuje, gdzie jest praca, i żadna z pozostałych tego nie zrekompensuje.

Kolejność ma znaczenie, bo sprawdzenie jest tanie: trasy są widoczne na jednej stronie, kontrola to jeden atrybut, a zdanie celu jest zwykle ostatnią rzeczą, o którą ktoś pyta.

Tłumaczenie zmienia to, które źródło widzi cel

Projekt z routingiem zachowuje adres źródłowy klienta, więc cel potrzebuje trasy powrotnej do prefiksu klienta. Projekt z tłumaczeniem przedstawia natomiast adres bramy, co usuwa to wymaganie i zastępuje je tabelą stanów na bramie. Decyduj zgodnie z zamierzoną architekturą, zamiast dodawać tłumaczenie, bo niepowiązany przykład go użył i wyglądał na działający.

Jeśli tłumaczysz, ogranicz regułę do prefiksu klienta i zamierzonego celu. Jeśli zachowujesz, potwierdź, że druga strona naprawdę zna trasę, zamiast zakładać, że się jej nauczy.

Testuj z oryginalnego klienta, a potem zachowaj zmianę

Żądanie wygenerowane na bramie może się powieść, podczas gdy żądanie przekazane zawodzi, bo to inne źródło i inny przypadek przekazywania. Po ukierunkowanej poprawce powtórz dokładnie ten test klient-do-zasobu, który zawiódł, z tego samego klienta, i potwierdź, że odpowiedź wraca, a nie tylko że żądanie dotarło.

Na koniec umieść ustawienie w zarządzanej konfiguracji bramy, aby instancja zastępcza je otrzymała. Udany test zależny od ręcznego wyjątku to test, który wygasa przy następnej przebudowie, a osoba, która go odkryła, nie będzie tam, by pamiętać dlaczego.