Android nu deschide fișierele din partajarea de fișiere prin VPN

Telefonul este în VPN, serverul de fișiere răspunde la ping, iar aplicația de fișiere tot raportează că nu se poate conecta, sau se conectează și niciun editor de pe dispozitiv nu deschide ce apare în listă. Sunt două defecțiuni diferite, și niciuna nu înseamnă că tunelul este stricat. Un VPN oferă doar o rută în rețeaua privată; a răsfoi o partajare, a te autentifica la ea și a preda un document altei aplicații sunt pași separați, cu moduri separate de eșec. Urmează ordinea în care le verific, și punctul în care mă opresc în loc să ghicesc.

Verifică serviciul înainte să dai vina pe tunel

Un răspuns la ping sau pagina web a NAS-ului dovedește doar rutarea și nimic altceva. Serviciul de care ai nevoie de fapt, SMB pe 445, SFTP pe 22 sau WebDAV pe 443, poate fi dezactivat, blocat de firewall sau legat de o interfață pe care subrețeaua VPN nu o poate atinge. De pe telefon, testează exact acel port cu un client care arată eroarea reală în loc de un mesaj generic de rețea. Dacă portul este filtrat, repară serviciul sau regula de firewall, pentru că nicio aplicație de fișiere nu poate ocoli un port închis.

Verifică și ce adresă de sursă vede serverul. Un tunel divizat care exclude subrețeaua partajării, sau un tunel per aplicație care lasă aplicația de fișiere în afara VPN-ului, produce exact simptomul conectat dar inaccesibil.

Rezistă tentației de a activa accesul de oaspete sau SMB1 pentru că un client nu se poate autentifica. Astfel de modificări lărgesc ce acceptă serverul pentru fiecare dispozitiv din rețea și nu repară nimic dacă problema de fond este rutarea sau rezolvarea numelor. Dacă partajarea cere un cont anume, folosește-l, inclusiv prefixul de domeniu sau grup de lucru pe care îl așteaptă serverul.

Folosește o aplicație de fișiere care vorbește protocolul singură

Android nu are un browser integrat pentru partajări de rețea, așa că aplicația client este o dependență reală, nu un detaliu. Alege una care implementează protocolul pe care îl folosești efectiv și care este încă întreținută, pentru că un client construit pentru o versiune de Android pe care nu o mai folosești eșuează în feluri care arată ca defecțiuni de rețea. Când descoperirea nu traversează subrețele, scrie gazda explicit în loc să aștepți ca aplicația să o găsească.

Încearcă serverul o dată după IP pentru a separa DNS de rutare. Dacă IP-ul funcționează și numele nu, telefonul rezolvă printr-un server DNS care nu vede zona ta privată.

Află ce primește aplicația destinatară: un URI, nu o cale

Dacă aplicația ta de fișiere implementează un DocumentsProvider, Storage Access Framework din Android poate arăta conținutul în selectorul de sistem, iar aplicația din care alegi primește un URI content:// plus o autorizație. Acea autorizație nu este o cale de sistem de fișiere, de aceea un editor care insistă pe un nume de cale brut nu poate deschide documentul, deși selectorul l-a listat. Ghidul Android privind accesul la documente descrie modelul: furnizorul deține octeții, iar consumatorul îi citește prin sistem. Aplicațiile care acceptă URI-ul funcționează, iar cele care apelează open() pe o cale nu. Acesta este cel mai frecvent motiv pentru care o partajare funcționează în aplicația de fișiere și eșuează oriunde altundeva.

Alternativa este o copie deliberată: adu fișierul în stocarea proprie a editorului, editează-l, apoi încarcă-l înapoi. Este un flux de lucru bun, dar creează o a doua copie și o întrebare despre conflicte, așa că decide care parte câștigă înainte să începi editarea într-un tren.

Politica VPN per aplicație merită și ea o privire aici. Pachetul care face citirea din rețea este adesea aplicația furnizor, nu editorul, așa că include pachetul corect în tunel în loc să judeci după pictograma pe care ai atins-o.

Testează separat citirea, scrierea și persistența permisiunii

O listare de director dovedește doar calea de citire. Folosește un fișier de test inofensiv și parcurge toată secvența: listează, deschide, editează, salvează, apoi redeschide același fișier dintr-un client desktop.

Urmărește persistența permisiunii după o repornire. Permisiunile de stocare sunt temporare dacă aplicația nu le preia persistent, iar unii editori le cer din nou la fiecare pornire, în timp ce alții eșuează în tăcere și îți arată o copie veche. Dacă o salvare pare reușită, confirmă-o pe partea serverului verificând timpul de modificare sau redeschizând din altă mașină. Testează și o deconectare în timpul salvării, pentru că o cădere a VPN-ului în timpul unui transfer este exact momentul în care un client lasă cel mai probabil un fișier parțial sau o modificare locală care nu se sincronizează niciodată.

Ține permisiunea URI din Android separată de autorizarea de pe server. Dreptul de a deschide un document nu spune nimic despre contul SMB din spatele lui.

Păstrează partajările montate pentru cazurile care au nevoie de ele

Montajele CIFS la nivel de root și modulele de sistem de fișiere din kernel încă există și dau fiecărei aplicații iluzia unui director local. Cer și root, se strică la schimbările de kernel și ascund defecțiunile de rețea în stratul de sistem de fișiere, unde sunt mai greu de diagnosticat. Pentru editarea documentelor pe un telefon, fluxul cu furnizor sau cu copiere acoperă cea mai mare parte din ce au nevoie oamenii de fapt.

Verifică dacă montajul supraviețuiește unei schimbări de rețea înainte să construiești un flux de lucru pe el. O partajare montată de pe un laptop pe un birou se comportă altfel decât un telefon care saltă între Wi-Fi și rețeaua mobilă, iar un montaj învechit poate face o aplicație să se blocheze în loc să eșueze curat.

Dacă tot ești blocat, parcurge lista în ordine și oprește-te la primul pas care eșuează: portul este accesibil, clientul de protocol este instalat, partajarea este autentificată, selectorul arată fișierul, editorul acceptă URI-ul, salvarea ajunge pe server. Acel pas îți spune ce componentă să repari și rareori este tunelul.