Profils, kas darbojas klēpjdatorā, neizdodas tālrunī. Acīmredzamais solis ir mainīt vienu vārdu klienta konfigurācijā. Šis vārds nepalīdzēs, jo abi gali nerunā par viena veida trafiku.

TAP pārsūta Ethernet kadrus. TUN pārsūta IP paketes. Android VPN lietotnei tiek dota IP saskarne, kas padara vienu no diviem izkārtojumiem iespējamu, bet otru ne, neatkarīgi no tā, ko saka konfigurācija.

Salīdzinājums ir īss, bet tas nosaka, vai varat to izlabot tālrunī vai jums ir jāmaina pakalpojums.

Divi tuneļu veidi ar atšķirīgu lietderīgo slodzi

TAP saskarne uzvedas kā Ethernet adapteris. Tā pārsūta kadrus, tas ir, ARP, apraidi un visu pārējo, ko LAN pārsūta zem IP. Tieši tas padara iespējamu tiltu: tunelis paplašina apraides domēnu, un klienti uzvedas tā, it kā būtu pievienoti komutatoram.

TUN saskarne pārsūta tai adresētās IP paketes. Nav saiknes slāņa, par ko vienoties, nav ARP un nav apraides. Maršrutēšana nosaka, kas nonāk tunelī, un servera puses konfigurācija izmanto apakštīklu, nevis tiltu.

Abiem galiem jāvienojas, kuru no šiem diviem tie dara. Mainot dev tap uz dev tun vienā pusē, pakalpojums netiek pārveidots; tiek iegūts klients, kas gaida maršrutētu tuneli, un serveris, kas joprojām sūta kadrus, un rokas sitiens var izdoties, kamēr nekas derīgs netiek cauri.

Ko Android patiešām dod lietotnei

Platformas VpnService API lietotnei dod virtuālu saskarni IP pakešu apstrādei, kas konfigurēta ar adresēm, maršrutiem un MTU. Šajā API nav Ethernet adaptera, un lietotne nevar to izdomāt.

Tāpēc OpenVPN Connect dokumentē maršrutētu TUN savienojumu atbalstu Android, nevis TAP tiltu. Android BUJ ir šīs robežas klienta puses paziņojums, un tas atbilst platformas API.

Tīkla rīki ar root tiesībām, pielāgota aparātprogrammatūra vai produkts, kas ievieš skaidru tulkošanas slāni, ir citi izkārtojumi. Parastais gadījums ir tas, ap ko jāplāno: lietotne, kas var importēt jūsu failu un darboties kā parasts lietotājs, ar IP saskarni un neko zem tās.

Kā tas izskatās, kad tomēr mēģināt

Savienojums parasti tiek izveidots. Tieši tas padara kļūmi mulsinošu: klients ziņo par savienojumu, servera žurnāls rāda partneri, un neviena lietotne nedarbojas.

Trafiks, kas adresēts tālrunim piešķirtajai adresei, nenonāk, jo serveris tiltā pārsūta kadrus uz MAC adresi, kādas tālrunim nekad nav bijis. No apraides atkarīgā atklāšana paliek tukša. Ja LAN paļaujas uz DHCP caur tiltu, tālrunis tā neiegūs nomu, un manuāli piešķirta adrese tiltotajā apakštīklā tomēr neizveido trūkstošo saskarni.

Daži klienti neizdodas agrāk, importējot profilu, kad ierauga ierīces veidu, ko nevar ieviest. Abas uzvedības nozīmē vienu un to pašu, un nevienu no tām neizlabo maršrutu pievienošana, DNS maiņa vai tuneļa adrešu diapazona paplašināšana.

Kas servera pusei ir jāmaina

Labojums pieder tam, kurš pārvalda VPN pakalpojumu, un tas parasti ir papildinājums, nevis migrācija. Palaidiet otru OpenVPN instanci ar maršrutētu ierīci, savu klientu apakštīklu un servera puses konfigurāciju, kas piešķir adreses un nosūta maršrutus, kas vajadzīgi tālruņiem. Esošā tiltotā instance turpina apkalpot ierīces, kurām tiešām vajag Ethernet.

Divi detaļas padara to praktiski funkcionējošu. LAN ir vajadzīgs atgriešanās maršruts jaunajam klientu apakštīklam, kas norāda uz VPN saimnieku, citādi atbildes nekad neatgriezīsies. Un ugunsmūrim tuneļa saimniekā jāpārsūta starp tuneļa saskarni un LAN, un tas ir solis, kas visbiežāk tiek izlaists, kad tests no paša saimnieka izdodas.

Ja operators nevar pievienot pakalpojumu, alternatīva ir ierīce, kas var pievienoties tiltam, tas ir, klēpjdators vai maršrutētājs, kas darbojas tālruņa vārdā. Tas ir apvedceļš ar savām pārvaldības izmaksām, nevis Android konfigurācija.

Izlemiet pēc lietotnes, nevis pēc tuneļa

Jautājiet, kam tālrunim patiešām jāpiekļūst, un pēc tam to kartējiet. Failu koplietošana vai intraneta vietne, kas sasniedzama pēc nosaukuma vai adreses, ir IP prasība, un maršrutēts tunelis to apmierina, tiklīdz DNS atrisina nosaukumu un maršruts pastāv. Atklāšanas rīks, kas pārlūko vietējo apraides domēnu, nav IP prasība, un nekāds maršrutēšanas apjoms to nepiepildīs.

RequirementTunnel that satisfies it
File server or intranet by hostnameRouted TUN, with working DNS
Broadcast or ARP-based discoveryEthernet bridging, so not an ordinary Android client
Multicast deliveryBridging or an explicit multicast relay
One application to one addressRouted TUN, narrowest possible route

Šī tabula ir arī nosūtāmais pieprasījums. Nosauciet lietotni, tās izmantoto adresi vai nosaukumu un to, vai tā ir atkarīga no atklāšanas. Operators var rīkoties pēc šī apraksta, ko neviens nevar izdarīt ar tālruni, kas nepievienojas.

Visbeidzot, paturiet TAP pakalpojumu tām ierīcēm, kurām tas vajadzīgs, tā vietā, lai liktu katram klientam atdarināt LAN adapteri. Divus pakalpojumus ar skaidriem mērķiem ir vieglāk atbalstīt nekā vienu, kas visiem darbojas uz pusi.

Saistītie raksti