Przekierowywanie portów na hotspocie Androida: trzy punkty wejścia

Włączyłeś hotspot, połączyłeś VPN, otworzyłeś port w aplikacji, a drugie urządzenie nadal nie może się połączyć. Brakującego elementu prawie nigdy nie stanowi sam port. Chodzi o to, która maszyna posiada gniazdo nasłuchujące i pod jaki adres ma trafić drugie urządzenie. Przechodzę przez to od telefonu na zewnątrz, ponieważ ekran, na którym jesteś, mówi, który z trzech punktów wejścia faktycznie testujesz.

Zacznij tam, gdzie usługa naprawdę działa

Otwórz aplikację, która ma przyjmować połączenie, i odczytaj jej stronę statusu. Jeśli twierdzi, że nasłuchuje, zapisz adres, do którego jest przypisana, bo ten jeden szczegół rozstrzyga większość przypadków poniżej. Aplikacja przypisana do 127.0.0.1 jest osiągalna tylko z samego telefonu i nie zmieni tego żaden klient hotspotu, mapowanie operatora ani wyjście VPN.

Następnie ustal, które urządzenie uruchamia usługę. To albo telefon, i wtedy gniazdo należy do tej aplikacji, albo laptop za hotspotem, i wtedy nasłuch oraz jego firewall należą do laptopa, a telefon tylko przekazuje pakiety. To różne projekty z różnymi właścicielami, a ich mieszanie jest powodem, dla którego port otwarty w jednym miejscu nic nie robi w drugim.

W kompilacji z debugowaniem adb shell może wylistować gniazda przez /proc/net/tcp, ale dla większości ludzi uczciwym źródłem jest status samej aplikacji. Pozwala też uniknąć pułapki testowania gniazda, które aplikacja otworzyła na adresie, którego się nie spodziewałeś.

Pierwszy punkt wejścia: inne urządzenie w hotspocie

To przypadek lokalny i najłatwiejszy do zrobienia poprawnie. Drugie urządzenie dociera do telefonu pod adresem, który widzi jako swoją bramę, na porcie, na którym nasłuchuje aplikacja, i nic poza hotspotem nie musi być zaangażowane. Mapowanie operatora nie jest potrzebne i żadna funkcja dostawcy nie musi istnieć, ponieważ ruch nigdy nie opuszcza segmentu lokalnego.

Psują to dwie rzeczy. Aplikacja jest przypisana do loopbacku albo polityka klienta w telefonie nie zezwala na połączenie lokalne. Testuj protokołem samej aplikacji, a nie gołym połączeniem TCP, jeśli aplikacja uwierzytelnia, bo nasłuch, który przyjmuje, a potem odrzuca, z dystansu wygląda identycznie jak zamknięty port.

Jeśli usługa działa na laptopie podłączonym do telefonu, adres hotspotu telefonu wcale nie jest celem. Potrzebujesz adresu laptopa w interfejsie hotspotu i nasłuchu na laptopie, a telefon nie jest już właścicielem niczego poza przekazywaniem.

Drugi punkt wejścia: ścieżka operatora

Dotarcie do telefonu z sieci komórkowej to inny problem i najczęściej po prostu nie działa dla IPv4. Operatorzy umieszczają aparaty za współdzielonym tłumaczeniem, dlatego RFC 6598 wyznaczył współdzielony zakres adresów dokładnie dla takiego układu. Niechciane połączenie przychodzące nie ma mapowania, przez które mogłoby przyjść, i żadna konfiguracja lokalna go nie tworzy, bo tłumacz nie jest twoim urządzeniem.

Dostęp root też tego nie zmienia. Daje kontrolę nad stosem telefonu, a nie nad tłumaczem operatora, a przepisy obiecujące coś przeciwnego zwykle zakładają publiczny adres, którego operator nigdy nie przydzielił. Tam, gdzie operator oferuje publiczny prefiks IPv6, ścieżka przychodząca może istnieć, ale nasłuch i firewall telefonu nadal wymagają świadomej autoryzacji, zanim cokolwiek odpowie.

Trzeci punkt wejścia: wyjście VPN

Adres, który strona internetowa podaje, gdy tunel jest aktywny, to adres wyjścia dla objętego ruchem wychodzącym. To nie to samo co adres przyjmujący połączenia przychodzące w twoim imieniu. Użycie go w ruchu przychodzącym wymaga funkcji, którą dostawca faktycznie oferuje, na przykład przekierowanego portu lub mapowania przychodzącego powiązanego z twoim kontem, plus użytecznej ścieżki od wyjścia do klienta.

Lokalna reguła zezwolenia nie może wytworzyć takiego mapowania. Może zmienić, którą ścieżką podążają odpowiedzi aplikacji, co ma znaczenie, gdy aplikacja jest wyłączona z tunelu: żądanie i odpowiedź mogą trafić do różnych kontekstów sieciowych, a połączenie zawodzi w sposób wyglądający jak problem z firewallem.

Przetestuj jedną ścieżkę od końca do końca, potem nazwij właściciela

Zapisz krotkę przed testem: zamierzony nadawca, adres docelowy, transport, port i maszynę, która posiada gniazdo nasłuchujące. Jeśli którykolwiek element jest domysłem, test nie powie ci nic użytecznego i skończysz, zmieniając drugą warstwę, aby wyjaśnić pierwszą.

Następnie przetestuj tę jedną autoryzowaną ścieżkę z nienaruszonym uwierzytelnianiem aplikacji. Unikaj publikowania szerokiego nasłuchu lub wyłączania niepowiązanych mechanizmów tylko po to, by niejednoznaczny test publicznego adresu odpowiedział, bo obie zmiany przetrwają test i żadna nie dowodzi, że projekt działa.

Podsystem tetheringu Androida przekazuje ruch w dół własną ścieżką, oddzielnie od zwykłego przechwytywania VPN przez aplikacje, więc działająca przeglądarka na podłączonym laptopie nic nie mówi o dostępie przychodzącym do usługi w telefonie. Zanim uznasz to za działające:

• Gniazdo nasłuchujące jest pod adresem osiągalnym dla zamierzonego peera, a nie na loopbacku.
• Peer używa adresu należącego do tego punktu wejścia, a nie adresu wyjścia ze strony statusu.
• Każde mapowanie po stronie operatora lub dostawcy jest obsługiwaną funkcją, a nie regułą dodaną lokalnie.
• Żądanie i odpowiedź przechodzą przez ten sam kontekst sieciowy, a uwierzytelnianie aplikacji nadal przechodzi.