LAN za jedną sesją AWS Client VPN: co jest przekazywane

Laptop łączy się z punktem końcowym AWS Client VPN, dociera do prywatnej podsieci i wszystko wygląda zdrowo. Pulpit w tej samej sieci LAN nie dociera do niczego, choć host Linux też ma interfejs mostu i obie maszyny są na tym samym kablu. W tunelu nic nie jest źle skonfigurowane; brakującym elementem jest routing, a most to fałszywy trop.

Rozszerzenie sesji Client VPN na LAN to rola bramy. To nie jest segment Ethernet rozciągnięty do usługi zarządzanej.

Host działa, a LAN nie

Interfejs tunelu na maszynie Linux ma adres w CIDR klienta Client VPN, a punkt końcowy wypchnął trasy dla zakresów VPC. Żądanie wykonane na tej maszynie to ruch generowany lokalnie: wybiera trasę, wychodzi przez tunel i otrzymuje odpowiedź. Ta ścieżka nigdy nie dotyka kodu przekazywania, interfejsu LAN ani żadnej reguły zapory, która rządzi tranzytem.

Ruch z innego urządzenia LAN to inny przepływ. Dociera do interfejsu LAN, potrzebuje trasy wskazującej do tunelu, potrzebuje włączonego przekazywania, potrzebuje zapory, która go dopuszcza, i potrzebuje, aby odpowiedź wróciła przez ten sam host. Cztery warunki, a działający test laptopa nie dowodzi żadnego. Z pulpitu awaria wygląda dziwnie: tunel jest podniesiony, dane uwierzytelniające są ważne, a cel po prostu nigdy nie odpowiada. Defekt jest lokalny w ścieżce przekazywania bramy, nie w usłudze.

Nie każdy klient może być bramą

AWS podaje, że jego aplikacja desktopowa Client VPN nie obsługuje przekazywania IP, a inne klienty mogą. To ograniczenie decyduje o architekturze, zanim zostanie wpisane jakiekolwiek polecenie. Jeśli jedynym dostępnym klientem jest oficjalna aplikacja desktopowa, brama Linux przekazująca dla LAN nie jest konfiguracją, którą można dokończyć, i żadna ilość masquerading tego nie zmieni.

Klient zastępczy musi też pasować do metody uwierzytelniania punktu końcowego i polityki, którą zamierzasz egzekwować. Punkty końcowe oparte na certyfikatach, katalogu i SAML nie akceptują tych samych konfiguracji klienta, a klient strony trzeciej, który się uwierzytelnia, ale ignoruje wypchnięte trasy, nie jest ulepszeniem.

Traktuj wybór klienta jako część przeglądu projektu. Decyduje on, czy wzorzec przekazywania LAN jest w ogóle dostępny, i decyduje, jaką tożsamość punkt końcowy widzi dla każdego urządzenia za bramą. Zapisz klienta i konfigurację punktu końcowego, przeciwko której go testowano. Wymiana klienta pół roku później może po cichu usunąć zdolność, którą projekt zakładał.

Skieruj LAN do tunelu i przetłumacz go

Mając obsługiwanego klienta na miejscu, reszta to zwykła praca bramy. Urządzenia LAN potrzebują trasy dla zakresu VPC wskazującej na host Linux, a host potrzebuje włączonego przekazywania. Jeśli chcesz, aby VPC widział ruch jako podłączonego klienta, a nie jako dowolny adres LAN, przetłumacz źródło na wyjściu.

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

Ogranicz regułę do interfejsu tunelu i zakresu VPC, jak wyżej, zamiast maskować wszystko, co host przekazuje. Węższa reguła jest łatwiejsza do przemyślenia i nie zmienia po cichu ruchu, który miał zachować oryginalny adres źródłowy.

Pozwól, aby trasa LAN pojawiała się automatycznie, jeśli możesz: opcja DHCP, ogłoszenie routera lub trasa statyczna wypychana przez to, co zarządza LAN. Trasa istniejąca tylko na jednej maszynie testowej sprawi, że projekt będzie wyglądał na zepsuty w chwili, gdy ktoś inny go wypróbuje.

Odpowiedź też potrzebuje ścieżki

Gdy żądanie dotrze do VPC, odpowiedź musi wrócić przez te same stany translacji i znaleźć trasę LAN na bramie. Ta część zwykle działa, gdy reguła masquerade jest na miejscu, bo mapowanie żyje na hoście, który je wykonał. Psuje się, gdy po stronie VPC jest trasa wysyłająca odpowiedź gdzie indziej, i dlatego znaczenie mają zarówno trasa CIDR klienta, jak i powiązanie podsieci w punkcie końcowym.

Patrz na liczniki, nie tylko na ping. Reguła masquerade z zerem pakietów mówi, że żądanie nigdy nie dotarło do interfejsu tunelu, co wskazuje z powrotem na trasę LAN lub własną tablicę routingu klienta. Reguła z pakietami, ale bez odpowiedzi, wskazuje na stronę VPC, reguły autoryzacji lub grupę zabezpieczeń, która nie akceptuje przetłumaczonego źródła. Czytaj oba kierunki, zanim coś zmienisz, bo liczba rosnąca tylko po jednej stronie to ścieżka jednokierunkowa, a nie wolna.

Pamiętaj, że punkt końcowy to usługa zarządzana. Nie ma pliku konfiguracji serwera do edycji ani dyrektywy client-config do dodania, więc instrukcje napisane dla samodzielnie zarządzanego serwera OpenVPN z niestandardowymi trasami podsieci klienta nie przenoszą się. W AWS dźwigniami są powiązanie podsieci, reguły autoryzacji i tabele routingu VPC.

Wspólna tożsamość to część, na którą musi odpowiedzieć polityka

Każde urządzenie za bramą korzysta z sesji VPN bramy. Reguły autoryzacji punktu końcowego przyznają dostęp użytkownikowi lub grupie, a z punktu widzenia usługi w tej sesji jest dokładnie jeden użytkownik. Lokalne przekazywanie nie mnoży tej tożsamości w uwierzytelnianie na urządzenie i nie rozciąga kontroli postury urządzeń na drukarkę w kącie.

To może być akceptowalne albo może być powodem odrzucenia projektu. Zależy to od tego, co zasoby VPC zakładają o tym, kto dzwoni. Wspólna tożsamość pasująca do modelu autoryzacji jest w porządku; ta, która po cichu zamienia jedną uwierzytelnioną sesję w dostęp do całej sieci LAN, jest ustaleniem czekającym na spisanie.

Jeśli wymaganiem jest naprawdę podłączenie całego obiektu do VPC, porównaj obsługiwany projekt lokacja-lokacja, zanim rozszerzysz klienta dostępu zdalnego. Semantyka jest inna, a sesja klienta z NAT to kiepski zamiennik łącza lokacji, gdy VPC musi inicjować połączenia do LAN.

Zdecyduj o kliencie, trasie, translacji i historii tożsamości w tej kolejności. Każde ogranicza następne, a kolejność wyjaśnia, dlaczego host działa, a LAN nie.