Android kan nie lêers op die VPN-lêerdeling oopmaak nie

Die selfoon is op die VPN, die lêerbediener antwoord op ’n ping, en die lêerprogram sê steeds dat hy nie kan konekteer nie; of hy konekteer en geen redigeerder op die toestel maak oop wat dit lys nie. Dit is twee verskillende foute, en nie een daarvan beteken die tonnel is stukkend nie. ’n VPN gee net ’n roete na die privaat netwerk; om deur ’n deling te blaai, by hom te verifieer en ’n dokument aan ’n ander program te gee, is aparte stappe met aparte maniere om te misluk. Hieronder volg die volgorde waarin ek dit nagaan, en die punt waar ek ophou eerder as om te raai.

Kontroleer die diens voordat jy die tonnel blameer

’n Antwoord op ’n ping of die NAS se webblad bewys net roetering, niks meer nie. Die diens wat jy werklik nodig het, SMB op 445, SFTP op 22 of WebDAV op 443, is dalk afgeskakel, deur die firewall geblokkeer of gebind aan ’n koppelvlak wat die VPN-subnet nie kan bereik nie. Toets daardie spesifieke poort van die selfoon af met ’n kliënt wat die werklike fout wys eerder as ’n algemene netwerkbanner. As die poort gefiltreer word, herstel die diens of die firewall-reël, want geen lêerprogram kan ’n geslote poort omseil nie.

Kyk ook watter bronadres die bediener sien. ’n Split-tonnel wat die deling se subnet uitsluit, of ’n tonnel per program wat die lêerprogram buite die VPN laat, lewer presies die simptoom gekoppel maar onbereikbaar.

Moenie die kortpad neem om gas toegang of SMB1 aan te skakel net omdat een kliënt nie kan verifieer nie. Sulke veranderinge verbreed wat die bediener vir elke toestel op die netwerk aanvaar, en hulle los niks op as die onderliggende probleem roetering of naamresolusie is. As die deling ’n spesifieke rekening nodig het, gebruik dit, insluitend die domein- of werkgroepvoorvoegsel wat die bediener verwag.

Gebruik ’n lêerprogram wat self die protokol praat

Android het geen ingeboude blaaier vir netwerkdelings nie, dus is die kliëntprogram ’n werklike afhanklikheid en nie ’n detail nie. Kies een wat die protokol implementeer wat jy werklik gebruik en wat nog onderhou word, want ’n kliënt wat vir ’n Android-weergawe gebou is wat jy nie meer gebruik nie, faal op maniere wat soos netwerkfoute lyk. Wanneer ontdekking nie subnette kruis nie, tik die gasheer uitdruklik in in plaas daarvan om te wag dat die program dit vind.

Probeer die bediener een keer per IP om DNS van roetering te skei. As die IP werk en die naam nie, los die selfoon op deur ’n DNS-bediener wat jou privaat sone nie kan sien nie.

Weet wat die ontvangende program kry: ’n URI, nie ’n pad nie

As jou lêerprogram ’n DocumentsProvider implementeer, kan Android se Storage Access Framework die inhoud in die stelselkieser wys, en die program wat jy kies, ontvang ’n content:// URI plus ’n toestemming. Daardie toestemming is nie ’n lêerstelselpad nie, en daarom kan ’n redigeerder wat op ’n rou padnaam aandring, die dokument nie oopmaak nie, al het die kieser dit gelys. Die Android-gids vir dokumenttoegang beskryf die model: die verskaffer besit die grepe en die verbruiker lees hulle deur die stelsel. Programme wat die URI aanvaar, werk; programme wat open() op ’n pad roep, werk nie. Dit is die algemeenste rede waarom ’n deling in die lêerprogram werk en oral elders faal.

Die alternatief is ’n doelbewuste kopie: trek die lêer in die redigeerder se eie berging in, wysig dit en laai dit terug. Dit is ’n goeie werkvloei, maar dit skep ’n tweede kopie en ’n konflikvraag, so besluit watter kant wen voordat jy op ’n trein begin redigeer.

Per-program VPN-beleid verdien hier ook aandag. Die pakket wat die netwerklees doen, is dikwels die verskafferprogram en nie die redigeerder nie, so sluit die regte pakket in die tonnel in in plaas daarvan om volgens die ikoon te oordeel.

Toets lees, skryf en die volharding van toestemmings afsonderlik

’n Gidslys bewys net die leespad. Gebruik ’n onskadelike toetslêer en loop die hele reeks: lys, maak oop, wysig, stoor en maak dieselfde lêer weer van ’n lessenaarkliënt oop.

Let op of toestemmings ná ’n herbegin bly staan. Bergingstoestemmings is tydelik tensy die program hulle blywend maak, en sommige redigeerders vra elke keer weer aan terwyl ander stil faal en vir jou ’n verouderde kopie wys. As ’n stoor suksesvol lyk, bevestig dit aan die bedienerkant deur die wysigingstyd te lees of van ’n ander masjien oop te maak. Toets ook ’n onderbreking tydens die stoor, want ’n VPN wat tydens ’n oplaai val, is presies wanneer ’n kliënt heel waarskynlik ’n gedeeltelike lêer of ’n plaaslike wysiging sonder sinchronisasie agterlaat.

Hou Android se URI-toestemming apart van die bediener se magtiging. Om toegelaat te word om ’n dokument oop te maak, sê niks oor die SMB-rekening daaronder nie.

Reserveer gemonteerde delings vir die gevalle wat dit nodig het

CIFS-monteerpunte op wortelvlak en kern-lêerstelselmodules bestaan nog, en hulle gee elke program die illusie van ’n plaaslike gids. Hulle vereis ook wortel, hulle breek by kernveranderings, en hulle versteek netwerkfoute in die lêerstelsellaag waar dit moeiliker is om te diagnoseer. Vir die wysiging van dokumente op ’n selfoon dek die verskaffer- of kopiewerkvloei meeste van wat mense werklik nodig het.

Kontroleer of die montering ’n netwerkverandering oorleef voordat jy ’n werkvloei daarop bou. ’n Deling wat van ’n skootrekenaar op ’n lessenaar gemonteer is, gedra hom anders as ’n selfoon wat tussen Wi-Fi en sellulêr spring, en ’n verouderde montering kan ’n program laat hang eerder as om netjies te faal.

As jy steeds vas is, werk die lys in volgorde deur en stop by die eerste stap wat faal: poort bereikbaar, protokolkliënt geïnstalleer, deling geverifieer, kieser wys die lêer, redigeerder aanvaar die URI, stoor beland op die bediener. Daardie stap wys watter komponent om te herstel, en dit is selde die tonnel.