TAP sau TUN? Clienți OpenVPN Android și servere cu punte

Un profil care funcționează pe un laptop eșuează pe telefon. Pasul evident este să modificați un cuvânt în configurația clientului. Acel cuvânt nu va ajuta, pentru că cele două capete nu vorbesc despre același tip de trafic.

TAP transportă cadre Ethernet. TUN transportă pachete IP. Unei aplicații VPN Android i se oferă o interfață IP, ceea ce face posibilă una dintre cele două aranjamente și nu pe cealaltă, indiferent ce spune configurația.

Comparația este scurtă, dar decide dacă puteți repara asta pe telefon sau trebuie să schimbați serviciul.

Două tipuri de tunel cu încărcături diferite

O interfață TAP se comportă ca un adaptor Ethernet. Transportă cadre, adică ARP, difuzare și tot ce transportă un LAN sub IP. Exact asta face puntea posibilă: tunelul extinde un domeniu de difuzare, iar clienții se comportă ca și cum ar fi conectați la un comutator.

O interfață TUN transportă pachete IP adresate ei. Nu există un strat de legătură de negociat, nici ARP, nici difuzare. Rutarea decide ce intră în tunel, iar configurația de pe server folosește o subrețea în loc de o punte.

Ambele capete trebuie să fie de acord care dintre cele două se întâmplă. Înlocuirea dev tap cu dev tun pe o parte nu transformă serviciul; produce un client care așteaptă un tunel rutat și un server care încă trimite cadre, iar handshake-ul poate reuși în timp ce nimic utilizabil nu trece.

Ce oferă Android de fapt aplicației

API-ul VpnService al platformei oferă unei aplicații o interfață virtuală pentru pachete IP, configurată cu adrese, rute și o MTU. În acel API nu există niciun adaptor Ethernet și nicio cale ca aplicația să inventeze unul.

De aceea OpenVPN Connect documentează suport pentru conexiuni TUN rutate pe Android, nu pentru punți TAP. Întrebările frecvente Android sunt declarația părții client despre această limită și corespund API-ului platformei.

Instrumentele de rețea cu root, firmware-ul personalizat sau un produs care implementează un strat explicit de traducere sunt alte aranjamente. Cazul obișnuit este cel pentru care trebuie să planificați: o aplicație care poate importa fișierul dumneavoastră și poate rula ca utilizator normal, cu o interfață IP și nimic dedesubt.

Cum arată când încercați totuși

Conexiunea se stabilește de obicei. Asta face eșecul confuz: clientul raportează conectat, jurnalul serverului arată un partener și nicio aplicație nu funcționează.

Traficul adresat adresei atribuite telefonului nu ajunge, pentru că serverul puntează cadre către o adresă MAC pe care telefonul nu a avut-o niciodată. Descoperirea bazată pe difuzare rămâne goală. Dacă LAN-ul depinde de DHCP prin punte, telefonul nu obține astfel o închiriere, iar o adresă atribuită manual în subrețeaua punteată tot nu creează interfața lipsă.

Unii clienți eșuează mai devreme, la importul profilului, când văd un tip de dispozitiv pe care nu îl pot implementa. Ambele comportamente înseamnă același lucru și niciunul nu se rezolvă adăugând rute, schimbând DNS-ul sau lărgind intervalul de adrese al tunelului.

Ce trebuie să schimbe partea de server

Corectura aparține celui care operează serviciul VPN și este de obicei o completare, nu o migrare. Rulați o a doua instanță OpenVPN cu un dispozitiv rutat, propria subrețea de clienți și o configurație pe server care atribuie adrese și împinge rutele de care au nevoie telefoanele. Instanța punteată existentă continuă să deservească dispozitivele care au într-adevăr nevoie de Ethernet.

Două detalii fac asta funcțional în practică. LAN-ul are nevoie de o rută de întoarcere pentru noua subrețea de clienți, îndreptată spre gazda VPN, altfel răspunsurile nu se întorc niciodată. Iar firewall-ul de pe gazda tunelului trebuie să transmită între interfața tunelului și LAN, iar acesta este pasul cel mai des omis când un test de pe gazda însăși reușește.

Dacă operatorul nu poate adăuga un serviciu, alternativa este un dispozitiv care se poate alătura punții, adică un laptop sau un router care acționează în numele telefonului. Este o soluție ocolitoare cu propriul cost de administrare, nu o configurație Android.

Decideți din aplicație, nu din tunel

Întrebați la ce trebuie să ajungă de fapt telefonul, apoi mapați. O partajare de fișiere sau un site de intranet accesat prin nume sau adresă este o cerință IP, iar un tunel rutat o satisface odată ce DNS-ul rezolvă numele și ruta există. Un instrument de descoperire care parcurge domeniul de difuzare local nu este o cerință IP și nicio cantitate de rutare nu îl va umple.

Tabelul acela este și cererea de trimis. Numiți aplicația, adresa sau numele pe care îl folosește și dacă depinde de descoperire. Un operator poate acționa pe baza acelei descrieri, ceea ce nimeni nu poate face cu un telefon care nu se conectează.

În final, păstrați serviciul TAP pentru dispozitivele care au nevoie de el în loc să faceți fiecare client să imite un adaptor LAN. Două servicii cu scopuri clare sunt mai ușor de susținut decât unul care funcționează pe jumătate pentru toți.