Strefy Shorewall dla dwóch ścieżek pakietów OpenVPN
Oddziel zaszyfrowany transport OpenVPN od odszyfrowanego ruchu klientów, daj tunelowi własną strefę i zezwól tylko na tę jedną usługę, której klient potrzebuje.
Dwa przepływy pakietów przechodzą przez bramę Shorewall, która kończy OpenVPN, i tylko jeden z nich jest zaszyfrowany. Pierwszy to transport klienta do nasłuchu VPN na interfejsie skierowanym do internetu. Drugi to odszyfrowane żądanie, które opuszcza interfejs tunelu, do serwera biurowego lub usługi na bramie. Zmapuj oba, zanim zmienisz politykę, ponieważ reguła spełniająca pierwszy nie robi nic dla drugiego.
Narysuj oba przepływy, zanim zmienisz politykę
Zapisz przepływy jako wiersze ze źródłem, celem, protokołem i portem. Na ścieżce zewnętrznej źródłem jest publiczny adres klienta, a celem port nasłuchu bramy; Shorewall traktuje to jako ruch z internetu do zapory. Na ścieżce wewnętrznej źródłem jest zakres adresów tunelu, a celem zatwierdzona usługa. Oba wiersze mają różnych właścicieli, nawet gdy jeden administrator utrzymuje oba.
| Flow | Zone relationship | What to constrain |
|---|---|---|
| Encrypted OpenVPN transport | Internet to the firewall host | The listener's actual protocol and port |
| Decrypted request to a LAN service | VPN clients to the LAN zone | One approved server and service |
| Decrypted request to the gateway | VPN clients to the firewall host | Only the local services required |
| Request to another VPN client | VPN clients to VPN clients | Denied unless deliberately required |
Dodaj wiersz tylko wtedy, gdy żądanie kończy się na samej bramie, na przykład dostęp do resolvera lub administracji. Usługa na hoście podlega polityce wejścia hosta, a nie ścieżce przekazywanej. Mieszanie obu jest tym, przez co wąska reguła tunelu w końcu ujawnia interfejs administracyjny.
Przypisz strefę tunelu i zakres interfejsu
Strefa podróżnego jest deklarowana w /etc/shorewall/zones, interfejs tunelu jest dołączany w /etc/shorewall/interfaces, a połączenie zewnętrzne jest opisane w /etc/shorewall/tunnels. Dopasuj się do składni zainstalowanego wydania, ponieważ kolejność kolumn i nazwy opcji zmieniły się między głównymi wersjami. Przykładowy port z przewodnika nie jest powodem, by zezwalać na port inny niż ten, na którym demon faktycznie nasłuchuje. TCP i UDP nie są wymienne tylko dlatego, że liczby się zgadzają.
Przewodnik grupuje interfejsy za pomocą tun+. Na hoście z więcej niż jednym tunelem ten znak wieloznaczny może umieścić drugi VPN o innym poziomie zaufania w tej samej strefie. Przejrzyj zakres względem interfejsów, które faktycznie istnieją, i trzymaj nazewnictwo w cyklu życia menedżera połączeń, zamiast ręcznie edytować nazwy interfejsów.
Historyczny przewodnik zawiera znacznie starsze przykłady konfiguracji OpenVPN, a jego porady kryptograficzne nie powinny być kopiowane do obecnego wdrożenia. Pożycz zamiast tego model stref i przepływów. Podstawę kryptograficzną weź z utrzymywanej polityki OpenVPN bramy.
Zezwól tylko na tę ścieżkę, którą sklasyfikowałeś
Szeroka akceptacja ze strefy VPN do LAN to schemat początkowy, a nie gotowa polityka. Zapisz dozwolone źródło klienta, rzeczywisty adres usługi, protokół i port. Następnie przeczytaj reguły powyżej i domyślną wartość strefy, ponieważ wąski dodatek nie unieważnia szerokiego zezwolenia, które już pasuje. Ruch do hosta bramy jest odrębną relacją od ruchu przekazywanego przez nią.
Ruch między klientami wymaga własnej decyzji. client-to-client OpenVPN i routeback Shorewalla wpływają na to, czy klienci mogą się nawzajem osiągnąć, i żadnego nie należy włączać tylko po to, by działała jedna aplikacja LAN. Zdecyduj, gdzie egzekwowana jest izolacja, zanim ją przetestujesz.
Utrzymaj ścieżkę powrotną w tym samym planie. Usługa lub jej router musi wiedzieć, jak zwrócić ruch do zakresu tunelu, albo projekt musi świadomie przekształcić źródło i to w zamierzonym zakresie.
Sprawdź, a następnie udowodnij obie ścieżki
Sprawdź konfigurację, zanim cokolwiek uruchomisz ponownie, i pozostaw otwartą niezależną sesję administracyjną na wypadek, gdyby nowa polityka była błędna.
shorewall checkPo czystym sprawdzeniu zastosuj konfigurację i odczytaj, co Shorewall załadował. Odczyty te opisują działającą politykę, a nie to, co plik zdaje się mówić.
shorewall show zones
ip route get 192.168.10.20Przetestuj jedno nowe dozwolone żądanie i jedno celowo odrzucone żądanie z tego samego klienta. Udany uścisk dłoni OpenVPN dowodzi tylko wymiany zewnętrznej; dozwolona usługa i odrzucony zasób dowodzą zamierzonej polityki wewnętrznej. Następnie połącz klienta ponownie i powtórz, ponieważ nazwa i adres interfejsu tunelu mogą się zmieniać między sesjami. Jeśli wynik się różni, popraw zakres strefy, a nie rozszerzaj reguły.