Az Android nem nyitja meg a fájlokat a VPN-megosztáson

A telefon a VPN-en van, a fájlszerver válaszol a pingre, és a fájlalkalmazás mégis azt írja, nem tud csatlakozni; vagy csatlakozik, és a készülék egyetlen szerkesztője sem nyitja meg azt, amit listáz. Ez két különböző hiba, és egyik sem jelenti azt, hogy az alagút elromlott. A VPN csak útvonalat ad a magánhálózatba; a megosztás böngészése, a hitelesítés rajta és a dokumentum átadása egy másik alkalmazásnak külön lépések, külön hibaokokkal. Az alábbiakban a sorrend, ahogy ellenőrzöm őket, és a pont, ahol megállok a találgatás helyett.

Ellenőrizze a szolgáltatást, mielőtt az alagutat hibáztatná

A pingre adott válasz vagy a NAS weboldala csak az útválasztást bizonyítja, semmi mást. A szolgáltatás, amire valóban szüksége van, az SMB a 445 porton, az SFTP a 22-n vagy a WebDAV a 443-on, lehet kikapcsolva, tűzfal által blokkolva vagy olyan interfészhez kötve, amelyet a VPN alhálózata nem ér el. A telefonról pontosan azt a portot tesztelje olyan klienssel, amely a valódi hibát mutatja, nem egy általános hálózati üzenetet. Ha a port szűrt, javítsa a szolgáltatást vagy a tűzfalszabályt, mert egyetlen fájlalkalmazás sem kerüli meg a zárt portot.

Azt is nézze meg, milyen forrás címet lát a szerver. Az osztott alagút, amely kizárja a megosztás alhálózatát, vagy az alkalmazásonkénti alagút, amely a fájlalkalmazást a VPN-en kívül hagyja, pontosan a csatlakoztatva de elérhetetlen tünetet adja.

Ne válassza a vendéghozzáférés vagy az SMB1 bekapcsolásának rövid útját csak azért, mert egy ügyfél nem tud hitelesíteni. Az ilyen változások kiterjesztik, mit fogad el a szerver a hálózat minden eszközétől, és semmit sem javítanak, ha az alapvető probléma az útválasztás vagy a névfeloldás.

Használjon olyan fájlalkalmazást, amely maga beszéli a protokollt

Az Androidnak nincs beépített böngészője a hálózati megosztásokhoz, ezért az ügyfélalkalmazás valódi függőség, nem részlet. Olyat válasszon, amely a ténylegesen használt protokollt valósítja meg, és még karbantartott, mert a már nem használt Android-verzióra épített kliens hálózati hibának látszó módon hibázik.

Próbálja ki a szervert egyszer IP-címmel, hogy elválassza a DNS-t az útválasztástól. Ha az IP működik és a név nem, a telefon olyan DNS-kiszolgálón keresztül old fel, amely nem látja a magánzónáját.

Mit kap a fogadó alkalmazás: URI-t, nem útvonalat

Ha a fájlalkalmazása DocumentsProvider-t valósít meg, az Android Storage Access Frameworkje megjelenítheti a tartalmát a rendszerválasztóban, és a kiválasztott alkalmazás content:// URI-t kap engedéllyel együtt. Ez az engedély nem fájlrendszer-útvonal, ezért a nyers útvonalat követelő szerkesztő nem tudja megnyitni a dokumentumot. Az Android dokumentumhozzáférési útmutatója leírja a modellt: a szolgáltató birtokolja a bájtokat, a fogyasztó a rendszeren keresztül olvassa őket.

Az alternatíva a szándékos másolat: húzza a fájlt a szerkesztő saját tárhelyére, szerkessze, majd töltse vissza. Ez jó munkafolyamat, de második példányt és ütközéskérdést teremt, ezért döntse el, melyik oldal nyer, mielőtt vonaton szerkeszteni kezd.

Az alkalmazásonkénti VPN-szabályzat is megér egy pillantást. A hálózati olvasást végző csomag gyakran a szolgáltató alkalmazás, nem a szerkesztő, ezért a megfelelő csomagot tegye az alagútba, ne az ikon alapján ítéljen.

Tesztelje külön az olvasást, az írást és az engedély tartósságát

Egy könyvtárlista csak az olvasási útvonalat bizonyítja. Vegyen egy ártalmatlan tesztfájlt, és járja végig a teljes sorrendet: listázás, megnyitás, szerkesztés, mentés, majd ugyanazon fájl újranyitása asztali kliensről.

Figyelje, hogy az engedély túléli-e az újraindítást. A tárhelyengedélyek ideiglenesek, hacsak az alkalmazás nem teszi őket állandóvá, és egyes szerkesztők minden indításnál újra kérdeznek, míg mások csendben meghiúsulnak és elavult másolatot mutatnak. Ha a mentés sikeresnek tűnik, erősítse meg a szerveren a módosítási idő alapján.

Tartsa külön az Android URI-engedélyét a szerver engedélyezésétől. A dokumentum megnyitásának engedélye semmit sem mond a mögötte lévő SMB-fiókról.

Tartsa fenn a csatolt megosztásokat azokra az esetekre, amelyeknek szükségük van rájuk

A gyökérszintű CIFS-csatolások és a kernel fájlrendszer-moduljai még léteznek, és minden alkalmazásnak helyi könyvtár illúzióját adják. Rootot igényelnek azonban, kernelváltozásoknál eltörnek, és a hálózati hibákat a fájlrendszer rétegében rejtik el, ahol nehezebb diagnosztizálni.

Ellenőrizze, hogy a csatolás túléli-e a hálózatváltást, mielőtt munkafolyamatot épít rá. Az asztalon laptopról csatolt megosztás másképp viselkedik, mint a Wi-Fi és mobilhálózat között ugráló telefon, és az elavult csatolás lefagyaszthatja az alkalmazást.

Ha még mindig elakadt, járja végig a listát sorrendben, és álljon meg az első hibázó lépésnél: a port elérhető, a protokollkliense telepítve, a megosztás hitelesítve, a választó mutatja a fájlt, a szerkesztő elfogadja az URI-t, a mentés megérkezik a szerverre. Ez a lépés megmondja, melyik összetevőt kell javítani, és ez ritkán az alagút.