Dlaczego EC2 nie dociera do Twojego laptopa AWS Client VPN
Client VPN tłumaczy źródła IPv4 klienta na interfejs sieciowy punktu końcowego. Dlatego odpowiedź działa, a nowe połączenie z EC2 nie.
Laptop połączony przez AWS Client VPN bez problemu dociera do aplikacji na EC2. Potem próbujesz odwrotnie, z EC2 na adres przydzielony klientowi, i połączenie zawiesza się lub jest odrzucane. Ta asymetria rzadko wynika z brakującej reguły grupy zabezpieczeń. W punkcie końcowym Client VPN powiązanym z podsieciami VPC AWS tłumaczy źródła IPv4 klienta na interfejs sieciowy punktu końcowego, więc nie istnieje adres VPC przychodzący, który reprezentuje Twój laptop.
Zacznij od tego, co pokazuje przechwycenie
Zrób przechwycenie na hoście EC2 podczas łączenia się klienta i odczytaj adres źródłowy, który aplikacja faktycznie widzi. Jeśli to interfejs punktu końcowego po stronie VPC, a nie adres z puli klientów, tłumaczenie jest potwierdzone, zanim zmienisz choć jedną regułę.
Pula klientów to zakres przydziału, a nie podsieć z trasą powrotną. Właśnie na tym rozróżnieniu większość takich dochodzeń się gubi.
Tłumaczenie, które wyjaśnia asymetrię
Trzy przepływy są ze sobą mylone, a tylko jeden z nich to ten, który ludzie testują.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Opis komponentów Client VPN wprost mówi, że źródła IPv4 klienta są tłumaczone na interfejs punktu końcowego, co wystarcza, by zobaczyć, dlaczego środkowy wiersz nie ma z czym się dopasować.
Nowe połączenie potrzebuje trasy, kroku rozwiązywania adresu i decyzji o autoryzacji. Stan tłumaczenia z cudzej sesji nie daje żadnego z tych trzech.
Dlaczego odpowiedź nie jest nowym połączeniem
Odpowiedź TCP jest dopasowywana do istniejącego wpisu, dlatego droga powrotna działa bez żadnej reguły przychodzącej. Świeży SYN z hosta EC2 nie ma wpisu do dopasowania, więc staje się zwykłą próbą wychodzącą do celu, do którego VPC nie wie, jak dotrzeć.
Dlatego też opisywanie tego jako ruchu idącego tylko w jedną stronę jest mylące. Ruch powrotny płynie w tych sesjach nieprzerwanie. Brak drogi dotyczy właśnie inicjowania.
Co nadal psuje sesję, która powinna działać
Grupy zabezpieczeń, sieciowe listy ACL i własna zapora laptopa mają znaczenie dla połączeń, które powinny się udać. Nieudany ping mówi najmniej, bo polityka ICMP często jest oddzielona od interesującej Cię polityki TCP.
Pisz te reguły względem przetłumaczonego źródła, a nie adresu klienta. Reguły przypięte do adresu, który nigdy nie pojawia się w sieci, to najczęstszy samodzielnie spowodowany błąd w tym projekcie.
Kiedy VPC naprawdę musi rozpocząć rozmowę
Jeśli usługa ma powiadomić stację roboczą, odwróć kierunek i pozwól klientowi utrzymywać stały kanał wychodzący, na który usługa odpowiada. Jeśli cała sieć zdalna ma być osiągalna z VPC, wybierz architekturę, która publikuje swoje prefiksy i politykę dostępu, zamiast zakładać, że Client VPN już to robi. Dostęp klient-klient to trzeci, węższy przypadek z własnymi obiektami trasy i autoryzacji. Żaden z nich nie jest tylko polem wyboru w istniejącym punkcie końcowym.
Zachowaj też uczciwy zakres wyjaśnienia IPv4. Obecna dokumentacja AWS oddziela IPv6, gdzie to tłumaczenie nie ma zastosowania, oraz inne modele podłączenia, które trasują inaczej.
Testuj w trzech oznaczonych krokach: klient otwiera dozwoloną sesję, usługa w VPC odpowiada na tę sesję, a host w VPC otwiera nową sesję w stronę klienta. To, że pierwsze dwa się udają, a trzeci zawodzi, jest oczekiwanym kształtem tego projektu, a nie usterką, którą trzeba ścigać regułami zapory.