Profil przypisany do serwera zawodzi za proxy TLS: która generacja?

Jeden użytkownik może się połączyć, a drugi nie, przez ten sam portal, tego samego dnia. Obaj mają profile przypisane do serwera, obaj są na tej samej kompilacji Access Server, a jedyna różnica to moment wygenerowania ich profilu. To wzorzec wart rozpoznania, ponieważ "przypisany do serwera" nazywa politykę, a nie sekwencję połączenia. Access Server dostarczył dwie generacje tego artefaktu, a odwrotne proxy TLS stoi tylko przed jedną z ich ścieżek. Trzy warunki decydują, na której gałęzi się znajdujesz.

Dwie generacje, dwie sekwencje połączenia

W starszym projekcie, obowiązującym do 2.8, importowany plik jest pseudoprofilem. OpenVPN Connect używa go do uwierzytelnienia w internetowym API Access Server przez HTTPS, otrzymuje tymczasowy profil przypisany do użytkownika i token sesji, i dopiero potem zestawia VPN. Dwa transporty działają kolejno, a pierwszy jest zwykłym żądaniem sieciowym.

Format wprowadzony w 2.9 nie wykonuje tego przygotowania przy każdym połączeniu. To profil natywny, którego mogą używać zgodne OpenVPN klienty, nie tylko OpenVPN Connect. Pobranie go lub zaimportowanie przez URL nadal może obejmować HTTPS — to krok publikacji, a nie pobieranie tymczasowego profilu przy każdym połączeniu.

Aktualizacja nie musi przepisywać już wydanych profili, więc bieżąca wersja serwera nadal może wydawać stary artefakt. Kompilacja serwera mówi, co jest możliwe, a nie co zaimportował ten użytkownik.

Trzy warunki, które wybierają Twoją gałąź

Pierwszym warunkiem jest generacja artefaktu. Poproś o plik, zobacz, jak powstał, i zapisz wersję klienta, który go zaimportował. Jeśli nie potrafisz ustalić generacji z pliku, świeży profil wydany dla konta testowego powie Ci, co serwer produkuje dzisiaj, a to inna informacja niż ta, którą ma zawodzący użytkownik.

Drugim jest to, co Twój front end faktycznie kończy. Odwrotne proxy HTTP warstwy siódmej, które zdejmuje TLS, nie jest tym samym obiektem co przekierowanie TCP warstwy czwartej, a przekierowanie UDP też nie. Zwykły układ Access Server na porcie 443 sprawia, że demon OpenVPN TCP rozpoznaje ruch przeglądarki i przekazuje go usługom sieciowym, więc wstawienie z przodu niepowiązanego terminatora HTTPS nie zachowuje obsługi protokołu tego demona. Wspólny numer 443 nie czyni dwóch projektów równoważnymi.

Trzecim jest to, gdzie ląduje błąd. Błąd przed VPN i błąd kanału sterowania wyglądają podobnie w kliencie, który mówi tylko "łączenie", ale zostawiają dowody w różnych miejscach. Jeśli w grę wchodzi stary format, przygotowanie jest kandydatem. Jeśli w grę wchodzi nowy format, pusty dziennik dostępu sieciowego jest oczekiwany i niczego nie dowodzi w żadną stronę.

Gdy artefakt jest stary: przygotowanie zawodzi pierwsze

Czytaj rzeczywisty błąd klienta, a nie jego stan końcowy. Interesujące pola to błąd HTTPS, tożsamość serwera, której klient oczekiwał, cel, do którego poszło żądanie, i to, czy walidacja certyfikatu została ukończona. Następnie porównaj je z dziennikami usługi sieciowej i proxy po stronie serwera.

Dotarcie przeglądarki do strony logowania nie jest dowodem, że uwierzytelnianie API tego klienta się powiodło. To różne żądania, z różnymi oczekiwaniami co do certyfikatu i często różnymi nazwami hostów. Jeśli portal jest obsługiwany poprawnie, a klient nadal zawodzi, rozbieżność jest na ścieżce przygotowania, a nie w haśle użytkownika.

Nie osiągaj powodzenia porównania przez wyłączenie weryfikacji TLS lub złagodzenie polityki uwierzytelniania. To zamienia diagnozowalną niezgodność konfiguracji w ścieżkę działającą, ale niezweryfikowaną, i właśnie ta zmiana zamienia tymczasowy test w trwałą dziurę. Dokumentacja Access Server dotycząca profili połączenia opisuje obie generacje i przepływ profilu tymczasowego, i to jest odniesienie, które należy sprawdzić, zanim uzna się, że winne jest proxy.

Gdy artefakt jest nowy: czytaj kanał sterowania

Z profilem w stylu 2.9 klient idzie prosto do natywnego punktu końcowego VPN. Zbadaj punkty końcowe w profilu, używany transport i błąd kanału sterowania. Jeśli klient nigdy nie wysyła żądania HTTP, jest to zgodne z projektem, a nie objaw.

Tu również pytanie o proxy zmienia kształt. Zdejmowanie HTTPS nie może zepsuć strumienia tylko TCP, którego nigdy nie widzi, ale nadal może zepsuć pobieranie, które publikuje profil, a przekierowanie tylko TCP w ogóle nie przeniesie UDP. Sprawdź, jakiego transportu wymaga profil, zanim uznasz, że front end nie ma znaczenia.

Przepuszczanie TLS dla jednego strumienia to wąski układ. Nie zapewnia przekierowania UDP i nie odtwarza własnego zachowania demona przy przekierowaniu usług na 443. Jeśli Twój front end robi jedną z tych rzeczy, powiedz którą, bo sposób naprawy jest inny.

Naprawy, które pozostają wąskie

Najmniej inwazyjnym sprawdzeniem jest wygenerowanie świeżego obsługiwanego profilu dla konta testowego i połączenie przez zamierzony natywny punkt końcowy z tymi samymi wymaganiami uwierzytelniania. Jeśli to działa, a zachowany stary profil nie, w jednym kroku oddzieliłeś artefakt od serwera i od proxy.

Dystrybucja profilu przypisanego do użytkownika całkowicie usuwa zależność od starego przygotowania, ponieważ nie ma wymiany tymczasowego profilu, która mogłaby zawieść. Musi być wydany zamierzonemu użytkownikowi, nigdy skopiowany od administratora, i zmienia to, do czego klient jest uprawniony, więc traktuj go jako decyzję polityki, a nie obejście.

Następnie popraw układ publikacji tak, aby istniała każda wymagana ścieżka: ścieżka sieciowa do pobierania i korzystania z portalu oraz natywna ścieżka VPN na transporcie, którego oczekują profile. Utrzymaj pracę proxy na jednej warstwie. Działający tunel przypisany do użytkownika dowodzi, że ta ścieżka działa; nie dowodzi, że każdy układ proxy obsługuje każdą generację, a stary błąd przygotowania nie potępia nowszego formatu.

• Ustal generację artefaktu, zanim dotkniesz proxy.
• Ustal, czy błąd występuje przed tunelem, czy w nim.
• Potwierdź, co kończy front end: HTTP, strumień TCP czy UDP.
• Przetestuj świeżo wydany profil wobec natywnego punktu końcowego z niezmienioną polityką.