TCP działa, a UDP trafia na inny serwer na tym samym porcie

Profil działa przez TCP i zawodzi przez UDP z ostrzeżeniem o certyfikacie. Intuicyjny odczyt jest taki, że ścieżka UDP zerwała zaufanie, a intuicyjna poprawka to zaakceptowanie certyfikatu. Oba założenia pomijają możliwość, która całkowicie wyjaśnia objaw: oba transporty dotarły do różnych maszyn. Reguła przekazywania jest dopasowywana dla każdego protokołu, a nic nie zmusza połówek TCP i UDP jednego numeru portu do wskazywania tego samego hosta.

Jeden numer portu, dwie niezależne reguły

Przekazywanie to wyszukiwanie w tabeli według protokołu, adresu docelowego i portu. Brama z regułą dla TCP 1194 i regułą dla UDP 1194 wyraża dwie niezależne decyzje, a mogą one wskazywać różne hosty wewnętrzne. Wspólny numer to udogodnienie dla ludzi, a nie właściwość wymuszana przez sieć. Traktuj numer portu jako etykietę, a nie definicję usługi.

Patrz na reguły obowiązujące, a nie zamierzone. Adres docelowy, przetłumaczony port i interfejs wejściowy biorą udział wszystkie, a pozostała reguła z wcześniejszej migracji jest zwykłą przyczyną niezgodności obu połówek.

Zapisz oba mapowania, zanim zmienisz cokolwiek innego. Para wierszy to cała hipoteza.

Co klient faktycznie sprawdził

Podczas uzgadniania klient sprawdza certyfikat względem skonfigurowanego zaufania i względem oczekiwanej nazwy. Nieoczekiwany certyfikat to udana weryfikacja, która nie przeszła kontroli tożsamości, i to jest właściwy wynik, gdy druga strona nie jest tą, do której chciałeś dotrzeć. Odrzucenie go jest dowodem, że klient działa, a nie że transport jest zepsuty. Czytaj zgłoszoną nazwę przed zgłoszonym łańcuchem, bo nazwa jest tym, co klient porównał.

Rozróżnienie ma znaczenie, bo oba błędy prowadzą do różnych poprawek. Problem zaufania wymaga poprawki zaufania, a nieoczekiwana strona wymaga poprawki routingu lub przekazywania.

Zapisz, jaką tożsamość zgłosił klient. Ta nazwa jest najsilniejszą wskazówką, która maszyna odpowiedziała.

Powiąż próbę z serwerem

Zapisz profil, adres publiczny, transport i port, których użył klient. Następnie dopasuj czas próby do dziennika serwera, do którego chciałeś dotrzeć. Brak wpisu jest wskazówką, a nie dowodem odrzucenia przez zaporę, ponieważ poziomy rejestrowania różnią się między wdrożeniami. Znacznik czasu wraz z adresem źródłowym zawęża to bardziej niż każde z nich osobno.

Porównaj napotkaną tożsamość certyfikatu z oczekiwaną tożsamością przez kanał administracyjny. To właśnie porównanie poza kanałem utrzymuje wiarygodność sprawdzenia.

Sprawdź stare reguły przekazywania, alternatywne nasłuchy i każdą ścieżkę równoważenia obciążenia, zanim uznasz, że oba transporty dzielą backend. Każdy z nich może przekierować przepływ, nie dotykając drugiego transportu.

Nie dopasowuj zaufania do niewłaściwej strony

Zaimportowanie nieoczekiwanego CA sprawia, że objaw znika, i zmienia, komu klient ufa. To gorszy stan niż nieudane połączenie, ponieważ ukrywa niezgodność, zamiast ją rozwiązywać. To samo dotyczy wyłączenia weryfikacji tylko po to, by sprawdzić, czy tunel wstanie.

Jeśli strona okaże się legalna, ale niezamierzona, właściwym działaniem jest wycofanie jej lub skierowanie reguły na właściwy host. Magazyn zaufania nie jest miejscem na uzgadnianie błędu inwentaryzacji.

Zachowaj tekst odrzucenia. To jedyny zapis tego, co widział klient.

Po poprawce przetestuj nowy przepływ

Popraw mapowanie, a następnie połącz się z nową sesją klienta. Tłumaczenie stanowe może utrzymywać istniejący przepływ na starym celu, więc ustanowione połączenie może przetrwać zmianę i wprowadzić cię w błąd. Rozpocznij nowe i potwierdź w dzienniku zamierzonego serwera, że obsłużył próbę.

Jeśli oba transporty udowodnione docierają do tego samego serwera i nadal zachowują się różnie, pozostałą różnicą są własne nasłuchy i konfiguracja tego serwera. Porównanie transportów ma sens dopiero wtedy, gdy tożsamość punktu końcowego jest ustalona.