Wyjątek UFW dla VPN, gdy zmienia się adres punktu końcowego

Klient próbuje połączyć się ponownie i nic nie opuszcza maszyny, chociaż ten sam profil działał w zeszłym tygodniu. Nazwa hosta punktu końcowego rozwiązuje się teraz na inny adres, a wyjątek wyjściowy nadal wskazuje stary. To jedno nieaktualne zezwolenie wystarcza, aby działający kill switch zmienić w całkowitą awarię, i jest niewidoczne w każdym wskaźniku stanu pokazywanym na pulpicie. Naprawa to mały przepływ pracy, a nie zmiana jednej linii.

Tunel łączy się ponownie, a potem nic już nie wychodzi

Reguła wyjściowa, która wskazuje adres docelowy, jest migawką, a odpowiedzi DNS nią nie są. Gdy dostawca obraca adres, pakiet wysyłany przez klienta do nowego peera nie pasuje do niczego i jest odrzucany przez domyślny zakaz. Klient zgłasza wtedy przekroczenie limitu czasu, co brzmi jak problem serwera, a nie zapory.

Przypięcie adresu, który zwraca publiczne wyszukiwanie, sprawia, że dziś działa, a jutro jest zepsute. To jednorazowa zmiana, a nie polityka utrzymania.

Opisz wyjątek, który naprawdę masz na myśli

Zacznij od zapisania czterech wartości, których potrzebuje reguła: zatwierdzona nazwa punktu końcowego lub zestaw adresów, transport, port docelowy i interfejs, przez który pakiet wychodzi. Wszystkie cztery są częścią zezwolenia i każde z nich może być błędne, podczas gdy reguła wciąż wygląda wiarygodnie. Reguła poprawna w trzech z nich zawodzi dokładnie tak samo jak reguła błędna we wszystkich czterech. Zapisz je, zanim wpiszesz polecenie, bo reguła jest tylko tak dobra jak opis, który za nią stoi.

Poniższe polecenie pokazuje postać dla jednego punktu końcowego IPv4 UDP na łączu kablowym. Zastąp obie wartości tymi, które zweryfikowałeś wobec wdrożenia.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

To zezwolenie nie autoryzuje dowolnych celów na tym samym porcie, nie tworzy nasłuchu i nie obejmuje TCP. Strona podręcznika UFW opisuje, jak adres, interfejs i protokół zawężają regułę, i właśnie to zawężenie jest całą istotą.

Odśwież to jako jeden przepływ pracy

Traktuj wyjątek jak zasób z właścicielem i przejściem, a nie jak polecenie, o którym ktoś pamięta. Najpierw pozyskaj kandydata z własnego resolvera i inwentarza punktów końcowych wdrożenia i świadomie zdefiniuj, jak ta nazwa jest rozwiązywana, zanim tunel powstanie. Następnie zweryfikuj kandydata wobec zamierzonego protokołu, portu i rodziny adresów, zanim dotkniesz zestawu reguł.

Zainstaluj najpierw nowe wąskie zezwolenie i potwierdź, że zostało wczytane, bo wysłanie klienta na adres, który zapora nadal blokuje, daje błąd wyglądający jak awaria serwera. Podczas zmiany pozostaw niepowiązane reguły nietknięte.

Obserwuj przejście klienta jego obsługiwaną ścieżką ponownego połączenia i potwierdź, który adres zdalny wybrał. Sama aktualizacja DNS nie przesuwa istniejącego gniazda, a ustawienie trwałości punktu końcowego może trzymać klienta na starym peerze długo po zmianie rekordu.

Na koniec celowo wycofaj przestarzałe zezwolenie, uwzględniając zatwierdzone okno nakładania się, gdy stara sesja jest jeszcze aktywna. Zbyt wczesne usunięcie starego wpisu powoduje krótką awarię; pozostawienie go na zawsze zostawia zezwolenie, którego nikt nie potrafi wyjaśnić.

Celowo wycofaj stare zezwolenie

Usuwanie to miejsce, w którym kryje się większość ryzyka, bo stara reguła jest jedyną rzeczą, która teraz działa. Jeśli instalacja kandydata się nie powiodła, nie kontynuuj i nie usuwaj wpisu, który nadal niesie ruch. Jeśli samo usuwanie się nie powiedzie, zapisz przestarzałe zezwolenie jako przestarzałe, zamiast ogłaszać politykę aktualną.

Powtórz cały przegląd, gdy łącze zmienia się z Ethernetu na Wi-Fi, gdy zmienia się transport lub gdy usługa obraca się między kilkoma adresami. Reguła specyficzna dla interfejsu ma przestać pasować po zmianie sieci, i takie zachowanie jest poprawne, choć wygląda jak regresja.

Udowodnij potem kontrakt nieszkodliwym ruchem. Zatwierdzony punkt końcowy musi być osiągalny podczas konfiguracji, chroniona aplikacja musi działać po połączeniu, a niepowiązany ruch bezpośredni musi pozostać zablokowany podczas awarii. Uwzględnij obie rodziny adresów i jedną celowo nieudaną próbę aktualizacji, bo połączenie, które udaje się po jednej zmianie przypiętego adresu, nie dowodzi żadnego z tych przypadków.