Android ne malfermas dosierojn en la VPN-kunhavigo

La telefono estas en la VPN, la dosierservilo respondas al ping, kaj la dosierapo ankoraŭ diras, ke ĝi ne povas konektiĝi; aŭ ĝi konektiĝas kaj neniu redaktilo en la aparato malfermas tion, kion ĝi listigas. Temas pri du malsamaj fiaskoj, kaj nek unu signifas, ke la tunelo estas rompita. VPN donas nur itineron en la privatan reton; foliumi kunhavigon, aŭtentikigi al ĝi kaj transdoni dokumenton al alia apo estas apartaj paŝoj kun apartaj manieroj fiaski. Sube estas la ordo, en kiu mi kontrolas ilin, kaj la punkto, kie mi haltas anstataŭ diveni.

Kontrolu la servon antaŭ ol kulpigi la tunelon

Respondo al ping aŭ la retpaĝo de la NAS pruvas nur enkursigon kaj nenion alian. La servo, kiun vi vere bezonas, SMB je 445, SFTP je 22 aŭ WebDAV je 443, povas esti malŝaltita, blokita de la fajroŝirmilo aŭ ligita al interfaco, kiun la VPN-subreto ne atingas. El la telefono testu ĝuste tiun pordon per kliento, kiu montras la veran eraron anstataŭ ĝenerala reta standardo. Se la pordo estas filtrita, ripari la servon aŭ la fajroŝirmilan regulon, ĉar neniu dosierapo povas ĉirkaŭiri fermitan pordon.

Kontrolu ankaŭ, kiun fontan adreson la servilo vidas. Disigita tunelo, kiu ekskludas la subreton de la kunhavigo, aŭ tunelo por unuopo, kiu lasas la dosierapon ekster la VPN, produktas ĝuste la simptomon konektita sed neatingebla.

Ne prenu la mallongigon per gastiga aliro aŭ SMB1 nur ĉar unu kliento ne povas aŭtentikigi. Tiaj ŝanĝoj larĝigas tion, kion la servilo akceptas por ĉiu aparato en la reto, kaj ili riparas nenion, se la baza problemo estas enkursigo aŭ nomresolvo.

Uzu dosierapon, kiu mem parolas la protokolon

Android ne havas enkonstruitan retumilon por retaj kunhavigoj, do la klienta apo estas vera dependeco, ne detalo. Elektu unu, kiu efektivigas la protokolon, kiun vi vere uzas, kaj ankoraŭ estas prizorgata, ĉar kliento konstruita por Android-versio, kiun vi ne plu uzas, fiaskas tiel, ke ĝi aspektas kiel reta paneo.

Provu la servilon per IP unufoje, por apartigi DNS de enkursigo. Se la IP funkcias kaj la nomo ne, la telefono solvas per DNS-servilo, kiu ne vidas vian privatan zonon.

Kion ricevas la akcepta apo: URI, ne vojo

Se via dosierapo efektivigas DocumentsProvider, la Storage Access Framework de Android povas montri ĝian enhavon en la sistema elektilo, kaj la apo, kiun vi elektas, ricevas content:// URI kun permeso. Tiu permeso ne estas dosiersistema vojo, tial redaktilo, kiu postulas krudan vojon, ne povas malfermi la dokumenton. La gvidilo de Android pri dokumenta aliro priskribas la modelon: la provizanto posedas la bajtojn kaj la konsumanto legas ilin tra la sistemo.

La alternativo estas intenca kopio: tiru la dosieron en la propran konservejon de la redaktilo, redaktu ĝin kaj resendu ĝin. Tio estas bona laborfluo, sed ĝi kreas duan kopion kaj konfliktan demandon, do decidu, kiu flanko venkas antaŭ ol redakti en trajno.

La VPN-politiko por unuopaj apoj ankaŭ meritas rigardon. La pako, kiu faras la retan legadon, ofte estas la provizanta apo, ne la redaktilo, do metu la ĝustan pakon en la tunelon anstataŭ juĝi laŭ la ikono.

Testu legadon, skribadon kaj daŭron de permeso aparte

Listo de dosierujo pruvas nur la legvojon. Uzu sendanĝeran testan dosieron kaj trapasu la tutan sinsekvon: listigi, malfermi, redakti, konservi, poste remalfermi la saman dosieron el labortabla kliento.

Atentu, ĉu la permeso restas post restarto. Konservaj permesoj estas provizoraj, se la apo ne faras ilin daŭraj, kaj iuj redaktiloj redemandas ĉe ĉiu lanĉo dum aliaj fiaskas silente kaj montras al vi malnovan kopion. Se konservo ŝajnas sukcesa, konfirmu ĝin ĉe la servilo per la modifotempo.

Tenu la URI-permeson de Android aparte de la rajtigo de la servilo. Rajto malfermi dokumenton diras nenion pri la SMB-konto malantaŭ ĝi.

Rezervu muntitajn kunhavigojn por la kazoj, kiuj bezonas ilin

CIFS-muntaĵoj je radika nivelo kaj kernaj dosiersistemaj moduloj ankoraŭ ekzistas, kaj ili donas al ĉiu apo la iluzion de loka dosierujo. Ili ankaŭ postulas radikon, rompiĝas ĉe kernaj ŝanĝoj, kaj kaŝas retajn paneojn en la dosiersistema tavolo, kie diagnozi estas pli malfacile.

Kontrolu, ĉu la muntaĵo postvivas retan ŝanĝon, antaŭ ol konstrui laborfluon sur ĝi. Kunhavigo muntita el tekokomputilo sur skribotablo kondutas alie ol telefono, kiu saltas inter Wi-Fi kaj poŝreto, kaj malnova muntaĵo povas haltigi apon.

Se vi ankoraŭ blokiĝas, trairu la liston laŭ ordo kaj haltu ĉe la unua paŝo, kiu fiaskas: pordo atingebla, protokola kliento instalita, kunhavigo aŭtentikigita, elektilo montras la dosieron, redaktilo akceptas la URI, konservo alvenas al la servilo. Tiu paŝo diras, kiun komponanton ripari, kaj ĝi malofte estas la tunelo.