Grupa bezpieczeństwa w chmurze dla VPN: otwórz port nasłuchu, nie wszystko

Serwer VPN działa, klient kończy na przekroczeniu czasu i pierwszy odruch to dodanie do grupy bezpieczeństwa reguły zezwalającej na wszystko. Czasem to sprawia, że działa, i to jest najgorszy wynik, bo teraz nikt nie wie, która granica naprawdę została zamknięta. Między klientem a demonem stoją cztery osobne filtry, a tylko jeden z nich to grupa bezpieczeństwa.

Nazwij protokół przed regułą

Reguła to protokół, zakres portów i źródło. WireGuard nasłuchuje na UDP, zwykle 51820. OpenVPN to zwykle UDP lub TCP 1194 w zależności od konfiguracji. IPsec potrzebuje wymiany IKE na UDP 500 i 4500 oraz samego protokołu ESP, który jest numerem protokołu, a nie portem. Zgadywanie TCP, bo inne reguły są TCP, prowadzi do reguły, która wygląda poprawnie i nie pasuje do niczego.

Czytaj nasłuch z działającej usługi, nie z poradnika. Demon związany z jednym adresem nie przyjmie ruchu przychodzącego na inny.

Ogranicz źródło do zakresu klientów, który dopuszcza projekt, a nie do całego internetu.

Grupy bezpieczeństwa są stanowe; ACL podsieci nie

Grupy bezpieczeństwa są stanowe i tylko zezwalają: dozwolony ruch przychodzący automatycznie otrzymuje odpowiedzi, a nie ma reguły odmowy, o której trzeba myśleć. ACL podsieci są bezstanowe i oceniane w obu kierunkach, więc zezwolenie przychodzące bez odpowiedniego wychodzącego zakresu efemerycznego nadal zawodzi. Ta różnica wyjaśnia wiele reguł, które w konsoli wyglądają poprawnie.

Sprawdź też, która polityka jest dołączona do działającego punktu końcowego, bo instancja może mieć więcej niż jedną grupę, a reguła w niepodłączonej grupie niczego nie zmienia.

Skuteczna polityka to suma tego, co dołączone, a nie plik, który edytowałeś.

Zapora hosta to odrębna granica

Polityka chmury wpuszcza ruch do interfejsu sieciowego, a potem system operacyjny decyduje, czy demon go zobaczy. Zapora hosta z domyślną polityką odmowy odrzuci pakiet, który grupa bezpieczeństwa dopuściła, a konsola chmury nie pokaże odmowy, bo nigdy nie miała zdania. Sprawdź jedno i drugie, w kolejności, w jakiej pakiet je napotyka.

Jeśli host korzysta z frontendu zapory dystrybucji, sprawdź reguły bazowe, a nie nazwę profilu, bo profil może być aktywny, gdy port jest zamknięty.

Przechwycenie na interfejsie mówi, która granica odrzuciła pakiet.

Dopuszczenie nasłuchu nie jest trasowaniem klientów

Brama VPN przekazująca ruch klientów potrzebuje więcej niż otwartego portu. Potrzebuje przekazywania IP, polityki zezwalającej na przepływ z interfejsu tunelu do sieci docelowej i często wyłączonego sprawdzania źródła i celu na interfejsie, aby platforma nie odrzucała ruchu niezaadresowanego do niej. Niczego z tego nie tworzy reguła nasłuchu.

Tu rozchodzą się działający uścisk dłoni i zepsuta ścieżka danych, dlatego status tunelu może wyglądać zdrowo, gdy nic się nie ładuje.

Napraw trasowanie jako osobną zmianę z własną weryfikacją i zauważ, że przekazująca brama potrzebuje też polityki wyjściowej zezwalającej na cel.

Zostaw drogę powrotną, a potem zawęź regułę

Przed zmianą polityki zdalnej zapory upewnij się, że istnieje niezależna ścieżka zarządzania, na przykład menedżer sesji, konsola szeregowa lub sieć poza pasmem. Jeśli jedyna ścieżka zarządzania biegnie przez regułę, którą edytujesz, nie masz odzyskiwania. Potem zastosuj wąską regułę, przetestuj z prawdziwego klienta i powiąż próbę z dowodami po stronie serwera. Odpowiedź innej usługi na tej samej maszynie nie jest dowodem, że nasłuch został osiągnięty.

Usuń wszelkie eksperymentalne szerokie zezwolenie, gdy tylko wąskie zadziała, i zapisz, dlaczego reguła istnieje. AWS dokumentuje stanowe zachowanie grup bezpieczeństwa i to ten dokument trzeba cytować, gdy ktoś proponuje szeroki zakres jako skrót.

Udokumentuj też dołączenie, inaczej zamienny interfejs po cichu utraci politykę.