Tryb SOCKS w NetGuardzie obejmuje TCP, nie każdy protokół

NetGuard zajmuje interfejs VPN Androida, aby filtrować ruch, i może przekazywać obsługiwane połączenia do punktu końcowego SOCKS. Te dwa fakty są często czytane jako „telefon jest w VPN”, co jest wnioskiem, którego mechanizm nie wspiera. Filtr widzi pakiety; proxy widzi tylko te połączenia, które faktycznie mu przekazano. Między tymi dwoma zdaniami leży całe pytanie o pokrycie.

FAQ projektu źródłowego dokumentuje zarówno ograniczenie do jednej usługi, jak i opcję SOCKS. Istnienie opcji nie jest dowodem, że korzysta z niej każdy dozwolony pakiet, i właśnie z tej luki biorą się pytania o pokrycie.

Dwie ścieżki przekazywania w jednej aplikacji

Strona TCP implementacji zawiera obsługę połączeń SOCKS, więc dozwolone połączenie TCP można wynegocjować z proxy i przeprowadzić przez nie. Strona UDP ma osobną ścieżkę gniazda, a jej obsługa wysyłania i odbioru nie zależy od tej negocjacji TCP. Dlatego datagram, który filtr dopuszcza, może dotrzeć do zwykłej sieci, nigdy nie przechodząc przez proxy. Nic z tego nie jest defektem aplikacji; to po prostu to, co implementują obie ścieżki.

To rozróżnienie ma konsekwencję, którą ludzie błędnie opisują w obu kierunkach. Nazywanie każdego pakietu UDP wyciekiem ignoruje reguły blokowania, bo odrzucony datagram nigdy nie wychodzi. Nazywanie całego układu VPN ignoruje dozwoloną ścieżkę bezpośrednią, bo część ruchu rzeczywiście wychodzi bez proxy. To, co masz, to filtrowane urządzenie z częściowym proxy, a uczciwy opis to macierz, a nie etykieta.

Reklamowanie UDP nie jest jego implementowaniem

Serwer SOCKS, który twierdzi, że obsługuje UDP, nie dodaje odpowiedniej obsługi po stronie klienta do aplikacji na twoim telefonie. Teoretyczne cechy protokołu i zachowanie zainstalowanej kompilacji to różne tematy, a tylko drugi opisuje twój ruch.

Sprawdź wersję i konfigurację, którą naprawdę uruchamiasz, następnie przetestuj nieszkodliwy przepływ datagramów i sprawdź, czy pojawia się w proxy. Wszystko inne to wnioski z listy funkcji, a listy funkcji opisują intencje, a nie ścieżki kodu.

DNS to trzecia ścieżka, nie szczegół

Rozwiązywanie nazw dodaje do macierzy własną gałąź. Lokalny przekazujący DNS, zwykłe zapytanie UDP, nazwa hosta docelowego rozwiązywana przez samo proxy i szyfrowany resolver w przeglądarce to cztery różne układy. Różnią się tym, kto widzi zapytanie i która ścieżka sieci je przenosi, a mieszanie ich daje test, który niczego nie dowodzi o pozostałych.

Zdecyduj świadomie, którego chcesz. Jeśli wymaganiem jest, aby nazwy były rozwiązywane przez tunel, samo ustawienie przeglądarki tego nie zapewni, a proxy, które samo rozwiązuje nazwy hostów, zmienia odpowiedź tylko dla połączeń, które naprawdę obsługuje.

Transport przez proxy nie jest automatycznie prywatny

Zwykły SOCKS nie jest szyfrowanym łączem od telefonu do proxy. Jeśli punkt końcowy jest osiągany inną chronioną ścieżką, nazwij tę ścieżkę i jej politykę awaryjną, bo powrót do otwartej sieci bez ostrzeżenia czyni prywatny układ publicznym. Ważne jest też uwierzytelnianie samego proxy: otwarty nasłuchiwacz na współdzielonym urządzeniu to usługa, z której nikt się nie rozlicza.

Układy między profilami zasługują na takie samo zbadanie. VPN profilu służbowego chroni tylko ruch korzystający z jego ścieżki, a współistnienie zapory profilu prywatnego z tunelem służbowym nie dowodzi, że dalsze połączenie zapory dociera do tego tunelu. Weryfikuj osiągalność i uwierzytelnianie, zamiast zakładać, że oba profile współpracują.

Audytuj pokrycie macierzą, a nie wczytaniem strony

Do autoryzowanej oceny wybierz nieszkodliwe przykłady reprezentujące każdą klasę, na której ci zależy: wymagany TCP, dozwolony UDP i DNS w obu rodzinach adresów. Dla każdego zapisz, czy był proxy, zablokowany czy wysłany bezpośrednio. Ta jedna tabela jest wynikiem i jest znacznie użyteczniejsza niż zrzut ekranu wczytanej strony.

Jeśli wymaganiem jest, aby cały wybrany ruch aplikacji przechodził przez zdalny tunel, wybierz implementację z jawnie obsługiwanym połączonym filtrowaniem i tunelowaniem. Kompozycja z samym proxy TCP pozostaje użyteczna do węższych zadań, pod warunkiem że pozostały ruch jest obsługiwany celowo, a nie zapomniany.