Android nie otwiera plików na udziale sieciowym przez VPN

Telefon jest w VPN, serwer plików odpowiada na ping, a aplikacja plików nadal zgłasza brak połączenia albo łączy się i żaden edytor na urządzeniu nie otwiera tego, co wyświetla. To dwie różne awarie i żadna z nich nie oznacza, że tunel jest zepsuty. VPN dostarcza tylko trasę do sieci prywatnej; przeglądanie udziału, uwierzytelnianie się w nim i przekazanie dokumentu innej aplikacji to osobne kroki z osobnymi sposobami zawodzenia. Poniżej podaję kolejność, w jakiej je sprawdzam, oraz moment, w którym przestaję zgadywać.

Sprawdź usługę, zanim obwinisz tunel

Odpowiedź na ping albo strona WWW NAS-a dowodzi tylko routingu i niczego więcej. Usługa, której naprawdę potrzebujesz, SMB na porcie 445, SFTP na 22 albo WebDAV na 443, może być wyłączona, zablokowana przez zaporę lub przypisana do interfejsu, do którego podsieć VPN nie dociera. Z telefonu przetestuj ten konkretny port klientem, który pokazuje prawdziwy błąd, a nie ogólny komunikat sieciowy. Jeśli port jest filtrowany, napraw usługę albo regułę zapory, bo żadna aplikacja plików nie obejdzie zamkniętego portu.

Sprawdź też, jaki adres źródłowy widzi serwer. Tunel dzielony, który wyklucza podsieć udziału, albo tunel per aplikacja, który zostawia aplikację plików poza VPN, daje dokładnie objaw połączenia bez dostępu.

Oprzyj się pokusie włączenia dostępu gościa albo SMB1, bo jeden klient nie potrafi się uwierzytelnić. Takie zmiany poszerzają to, co serwer akceptuje od każdego urządzenia w sieci, i niczego nie naprawiają, jeśli przyczyną jest routing albo rozwiązywanie nazw. Jeśli udział wymaga konkretnego konta, użyj go, wraz z prefiksem domeny lub grupy roboczej, którego oczekuje serwer.

Użyj aplikacji plików, która sama obsługuje protokół

Android nie ma wbudowanej przeglądarki udziałów sieciowych, więc aplikacja klienta jest realną zależnością, a nie szczegółem. Wybierz taką, która implementuje protokół, którego naprawdę używasz, i jest nadal utrzymywana, bo klient zbudowany pod wersję Androida, której już nie używasz, zawodzi w sposób przypominający awarie sieci. Gdy wykrywanie nie przechodzi między podsieciami, wpisz hosta ręcznie, zamiast czekać, aż aplikacja go znajdzie.

Wypróbuj serwer raz po adresie IP, aby oddzielić DNS od routingu. Jeśli IP działa, a nazwa nie, telefon rozwiązuje nazwy przez serwer DNS, który nie widzi twojej strefy prywatnej.

Wiedz, co dostaje aplikacja odbierająca: URI, a nie ścieżkę

Jeśli twoja aplikacja plików implementuje DocumentsProvider, framework Storage Access Framework w Androidzie może pokazać jej zawartość w systemowym selektorze, a aplikacja, którą wybierzesz, otrzymuje URI content:// oraz nadanie uprawnień. To nadanie nie jest ścieżką w systemie plików, dlatego edytor wymagający surowej nazwy ścieżki nie otworzy dokumentu, mimo że selektor go wyświetlił. Przewodnik Androida po dostępie do dokumentów opisuje ten model: dostawca jest właścicielem bajtów, a odbiorca czyta je przez system. Aplikacje przyjmujące URI działają, a aplikacje wywołujące open() na ścieżce nie. To najczęstsza przyczyna tego, że udział działa w aplikacji plików i zawodzi wszędzie indziej.

Alternatywą jest świadome kopiowanie: ściągnij plik do własnej pamięci edytora, zmień go, a potem wgraj z powrotem. To dobry sposób pracy, ale tworzy drugą kopię i pytanie o konflikt, więc zdecyduj, która strona wygrywa, zanim zaczniesz edytować w pociągu.

Polityka VPN per aplikacja też zasługuje tu na uwagę. Pakiet, który wykonuje odczyt sieciowy, to często aplikacja dostawcy, a nie edytor, więc obejmij tunelem właściwy pakiet, zamiast oceniać po ikonie, którą dotknąłeś.

Testuj odczyt, zapis i trwałość uprawnień osobno

Lista katalogu dowodzi tylko ścieżki odczytu. Użyj nieszkodliwego pliku testowego i przejdź całą sekwencję: wyświetl, otwórz, zmień, zapisz, a potem otwórz ten sam plik ponownie z klienta na komputerze.

Obserwuj trwałość uprawnień po restarcie. Uprawnienia do pamięci są tymczasowe, chyba że aplikacja przyjmuje je na stałe, a niektóre edytory pytają o nie przy każdym uruchomieniu, podczas gdy inne zawodzą po cichu i pokazują nieaktualną kopię. Jeśli zapis wygląda na udany, potwierdź go po stronie serwera, sprawdzając czas modyfikacji albo otwierając plik z innej maszyny. Przetestuj też rozłączenie w trakcie zapisu, bo zerwanie VPN podczas wysyłania to dokładnie ten moment, w którym klient najczęściej zostawia częściowy plik albo lokalną zmianę, która nigdy się nie zsynchronizuje.

Trzymaj uprawnienie URI w Androidzie osobno od autoryzacji na serwerze. Prawo do otwarcia dokumentu nie mówi nic o koncie SMB, które za nim stoi.

Zarezerwuj montowane udziały dla przypadków, które ich potrzebują

Montowania CIFS na poziomie roota i moduły systemów plików w jądrze nadal istnieją i dają każdej aplikacji złudzenie lokalnego katalogu. Wymagają też roota, psują się przy zmianach jądra i ukrywają awarie sieci w warstwie systemu plików, gdzie trudniej je zdiagnozować. Do edycji dokumentów na telefonie przepływ z dostawcą albo kopiowaniem pokrywa większość tego, czego ludzie naprawdę potrzebują.

Sprawdź, czy montowanie przetrwa zmianę sieci, zanim zbudujesz na nim sposób pracy. Udział zamontowany z laptopa na biurku zachowuje się inaczej niż telefon przeskakujący między Wi-Fi a siecią komórkową, a nieaktualne montowanie może zawiesić aplikację zamiast spowodować czysty błąd.

Jeśli nadal utknąłeś, przejdź listę po kolei i zatrzymaj się na pierwszym kroku, który zawodzi: port osiągalny, klient protokołu zainstalowany, udział uwierzytelniony, selektor pokazuje plik, edytor przyjmuje URI, zapis trafia na serwer. Ten krok mówi, który element naprawić, i rzadko jest to tunel.