Klienci VPN a sieć LAN: kiedy używać osobnej strefy

Umieszczenie interfejsu tunelu w strefie LAN to najkrótsza droga do działającego VPN i zwykle jest to błędne ustawienie domyślne. Daje zdalnemu klientowi takie samo zaufanie jak sieć LAN z kablem, czego zadanie rzadko wymaga. Osobna strefa kosztuje kilka reguł i czyni granicę widoczną. Decyzja nie dotyczy tego, czy strefy są lepsze; dotyczy tego, które trzy warunki dotyczą twojej sieci.

Nazwa strefy niczego nie szyfruje i nie uwierzytelnia użytkownika. Grupuje jedynie interfejsy na potrzeby modelu polityk zapory.

Co naprawdę kontroluje przynależność do strefy

Strefa grupuje interfejsy lub ruch w modelu zapory. Następnie jej ustawienia wejścia, wyjścia i przekazywania rządzą różnymi rolami. Wejście to ruch do samego routera; przekazywanie to ruch przez niego do innego hosta. Dokumentacja stref OpenWrt traktuje wejście, wyjście i przekazywanie jako osobne ustawienia dokładnie z tego powodu.

Zezwolenie ze strefy VPN do strefy LAN nie jest automatycznie zezwoleniem odwrotnym. Reguły przekazywania są kierunkowe, a reguła zezwalająca na ruch od klienta do serwera nie zezwala na sesje od serwera do klienta. Klient, który może otworzyć połączenie do serwera, nie jest klientem, do którego serwer może otworzyć połączenie zwrotne.

Ta różnica jest powodem, dla którego osobna strefa jest przydatna: możesz wyraźnie wskazać każdy kierunek i każdą rolę. Zapisuj kierunek obok każdej reguły.

Decyzja pierwsza: wejście, przekazywanie czy oba

Jeśli zdalni klienci potrzebują DNS z routera, zezwól na wejście tylko dla tej usługi. Jeśli muszą dotrzeć do serwera plików, zezwól na przekazywanie do tego celu. Większość projektów VPN potrzebuje obu, ale dla różnych usług.

Szeroki dostęp przez wejście do wszystkich usług lokalnych prawie nigdy nie jest potrzebny. Traktuj zarządzanie routerem jako osobną decyzję od dostępu do aplikacji. Jeśli router ma tylko odpowiadać na DNS, zapisz to jedno zezwolenie, a resztę pozostaw zamkniętą.

Decyzja druga: jakich zasobów potrzebują zdalni klienci

Wypisz zakresy klientów, cele i usługi, które VPN ma zapewniać, zanim napiszesz reguły. Lista celów jest bardziej użyteczna niż etykieta zaufania, ponieważ przetrwa migrację zapory.

Trzymaj interfejsy zarządzania osobno od zwykłego dostępu do aplikacji. Zdalny klient, który dociera do wiki, nie potrzebuje przez to strony administracyjnej routera ani konsoli hiperwizora.

Jeśli dozwolony cel może przekazywać dalej, granica strefy kończy się na zaporze, a nie na tym, co cel robi dalej.

Decyzja trzecia: jak udowodnisz granicę

Po każdej zmianie przetestuj przepływ dozwolony i jeden celowo zablokowany. Udowodnienie, że jedna strona się wczytuje, nie ujawnia niezamierzonego szerokiego zezwolenia. Testuj z zakresu adresów klienta VPN, nie z sieci LAN, i uwzględnij kierunek, w którym spodziewasz się niepowodzenia. Zapisz oba wyniki obok reguły.

Zachowaj dostęp odzyskiwania bramy, zanim zmienisz politykę zdalnej strefy. Używaj trwałej zarządzanej konfiguracji zamiast zmian w czasie działania, inaczej następny restart przywróci stare zaufanie. Kopia poprzedniej konfiguracji, przechowywana poza urządzeniem, to najtańsze wycofanie, jakie kiedykolwiek będziesz mieć.

Gdy sieć rośnie, dokumentuj przynależność i cel reguł. Nowo podłączony interfejs nie powinien dziedziczyć uprawnień tylko dlatego, że ktoś nadał mu wygodną nazwę strefy.