Reset TCP nie dowodzi, że Twoja VPN jest blokowana

W dzienniku klienta pojawia się „połączenie zresetowane, ponowne uruchamianie”, a wniosek przychodzi przed dowodem. Ktoś decyduje, że sieć blokuje VPN, albo że certyfikat jest błędny, albo że jakieś państwo ingeruje. Reset to pakiet TCP, który kończy połączenie, a wiersz dziennika odnotowuje, że Twój klient go otrzymał. Nie podaje nazwy urządzenia, które go wysłało, ani przyczyny.

Reset to pakiet, nie wyrok

TCP definiuje obsługę resetu: segment z flagą RST natychmiast kończy połączenie. Odbiorca nie negocjuje, nie ponawia i nie pyta dlaczego. Zgłasza reset i idzie dalej.

To wszystko, co wie klient. RST mógł przyjść z serwera, z proxy, z zapory lub z równoważenia obciążenia, które utraciło stan.

Ustalenie pochodzenia to osobne ćwiczenie. Pozorny adres źródłowy w przechwyceniu nie jest dowodem pochodzenia fizycznego i nic nie mówi o decyzji polityki stojącej za nim. Urządzenia pośredniczące mogą fałszować adresy, a urządzenia stanowe mogą resetować z powodu przekroczenia czasu, a nie zamiaru. Traktowanie resetu jako wyroku pomija część, w której się tego dowiadujesz.

Potwierdź, które połączenie zostało zresetowane

Najpierw sprawdź, czy aktywny profil rzeczywiście używa TCP. Reset w tunelu UDP nie ma sensu, a dziennik proxy HTTP może dotyczyć innego odcinka TCP niż sama VPN.

Zanotuj cel, port, czas próby i etap, do którego dotarł klient.

Etap to najbardziej użyteczne pole. Reset podczas uzgadniania TLS wskazuje na jeden zestaw podejrzanych; reset po uwierzytelnieniu na inny. Bez etapu pasuje każda teoria.

Porównaj oba końce ścieżki

Jeśli administrujesz serwerem, porównaj jego zdarzenia dla tej samej próby. Czy zaakceptował połączenie? Czy zamknął je celowo? Czy odpowiedź opuściła jedną granicę i nigdy nie dotarła do następnej?

Przechwyć ruch u klienta i u serwera, jeśli możesz. Reset widoczny u klienta, ale nie u serwera, nie powstał na serwerze.

Obserwuj segmenty RST w obu kierunkach:

sudo tcpdump -ni any 'tcp[tcpflags] & tcp-rst != 0' -c 20
ss -tnp | grep 198.51.100.20

Zawęź za pomocą kontrolowanego porównania

Druga zatwierdzona sieć może powiedzieć, czy awaria podąża za klientem, czy za ścieżką. Jeśli ten sam profil działa gdzie indziej, konfiguracja klienta jest prawdopodobnie w porządku, a zmienną jest ścieżka.

To wciąż nie wskazuje jednego konkretnego urządzenia pośredniczącego. Zawęża zakres do trasy, co jest użytecznym i uczciwym wynikiem.

Zachowaj rozróżnienie między „ta ścieżka zawodzi” a „ten nazwany podmiot to spowodował”. Pierwsze jest testowalne; drugie zwykle nie z jednego klienta.

Sprawdź poprawkę bez zmiany ustawień zaufania

Nie wyłączaj weryfikacji TLS, nie generuj ponownie poświadczeń i nie ogłaszaj polityki blokowania na podstawie jednego wiersza resetu. Każda z tych zmian zmienia testowany system i czyni następne porównanie bezsensownym.

Napraw zidentyfikowany komponent przez jego właściciela, a następnie powtórz ten sam profil i tę samą obserwację:

openvpn --config client.ovpn --verb 4
sudo tcpdump -ni any 'host 198.51.100.20 and tcp' -c 40

Użytecznym wynikiem jest lepiej zlokalizowana awaria, a nie pewniejsza historia. Jeśli reset znika po naprawie proxy, masz przyczynę. Jeśli przenosi się na inny etap, dowiedziałeś się czegoś o ścieżce. Tak czy inaczej, dowód powinien przetrwać czytanie przez drugą osobę. Zapisz to, co zaobserwowałeś, a nie to, co wywnioskowałeś.