TAP apo TUN? Klientët OpenVPN për Android dhe serverat me urë

Një profil që funksionon në laptop dështon në telefon. Hapi i dukshëm është të ndryshoni një fjalë në konfigurimin e klientit. Ajo fjalë nuk do të ndihmojë, sepse dy skajet nuk flasin për të njëjtin lloj trafiku.

TAP transporton kuadro Ethernet. TUN transporton paketa IP. Një aplikacioni VPN për Android i jepet një ndërfaqe IP, gjë që e bën të mundur njërën nga dy rregullimet dhe jo tjetrën, pavarësisht se çfarë thotë konfigurimi.

Krahasimi është i shkurtër, por vendos nëse mund ta rregulloni në telefon apo duhet të ndryshoni shërbimin.

Dy lloje tunelesh me ngarkesa të ndryshme

Një ndërfaqe TAP sillet si përshtatës Ethernet. Transporton kuadro, domethënë ARP, transmetim dhe çdo gjë tjetër që një LAN transporton nën IP. Kjo është ajo që e bën të mundur urën: tuneli zgjat një domen transmetimi dhe klientët sillen sikur të ishin të lidhur me një komutator.

Një ndërfaqe TUN transporton paketa IP të adresuara drejt saj. Nuk ka shtresë lidhjeje për të negociuar, as ARP dhe as transmetim. Ushtrimi i rrugëzimit vendos çfarë hyn në tunel, dhe konfigurimi në anën e serverit përdor një nënrrjet në vend të një ure.

Të dy skajet duhet të bien dakord se cilën nga të dyja po bëjnë. Zëvendësimi i dev tap me dev tun në njërën anë nuk e konverton shërbimin; prodhon një klient që pret një tunel të rrugëzuar dhe një server që vazhdon të dërgojë kuadro, dhe shtrëngimi i duarve mund të ketë sukses ndërsa asgjë e përdorshme nuk kalon.

Çfarë i jep Android në të vërtetë aplikacionit

API VpnService i platformës i jep aplikacionit një ndërfaqe virtuale për paketat IP, të konfiguruar me adresa, rrugë dhe një MTU. Në atë API nuk ka asnjë përshtatës Ethernet, dhe aplikacioni nuk mund të shpikë një.

Prandaj OpenVPN Connect dokumenton mbështetje për lidhje TUN të rrugëzuara në Android dhe jo për ura TAP. Pyetjet e shpeshta për Android janë deklarata e anës së klientit për këtë kufi, dhe përputhet me API-në e platformës.

Mjetet e rrjetit me root, firmware i personalizuar ose një produkt që zbaton një shtresë të qartë përkthimi janë rregullime të tjera. Rasti i zakonshëm është ai rreth të cilit duhet planifikuar: një aplikacion që mund të importojë skedarin tuaj dhe të funksionojë si përdorues normal, me një ndërfaqe IP dhe asgjë nën të.

Si duket kur provoni gjithsesi

Lidhja zakonisht vendoset. Kjo është ajo që e bën dështimin konfuz: klienti raporton i lidhur, regjistri i serverit tregon një palë, dhe asnjë aplikacion nuk funksionon.

Trafiku i adresuar drejt adresës së caktuar të telefonit nuk mbërrin, sepse serveri urëzon kuadro drejt një adrese MAC që telefoni nuk e ka pasur kurrë. Zbulimi i varur nga transmetimi mbetet bosh. Nëse LAN-i mbështetet në DHCP përmes urës, telefoni nuk merr një qiradhënie në atë mënyrë, dhe një adresë e caktuar me dorë në nënrrjetin e urëzuar prapë nuk krijon ndërfaqen që mungon.

Disa klientë dështojnë më herët, në importimin e profilit, kur shohin një lloj pajisjeje që nuk mund ta zbatojnë. Të dyja sjelljet nënkuptojnë të njëjtën gjë, dhe asnjëra nuk rregullohet duke shtuar rrugë, duke ndryshuar DNS ose duke zgjeruar diapazonin e adresave të tunelit.

Çfarë duhet të ndryshojë ana e serverit

Rregullimi i takon atij që operon shërbimin VPN, dhe zakonisht është shtesë dhe jo migrim. Nisni një instancë të dytë OpenVPN me një pajisje të rrugëzuar, nënrrjetin e vet të klientëve dhe një konfigurim në anën e serverit që cakton adresa dhe shtyn rrugët që u duhen telefonave. Instanca ekzistuese e urëzuar vazhdon t'u shërbejë pajisjeve që kanë vërtet nevojë për Ethernet.

Dy detaje e bëjnë këtë funksional në praktikë. LAN-it i duhet një rrugë kthimi për nënrrjetin e ri të klientëve, që tregon drejt hostit VPN, përndryshe përgjigjet nuk kthehen kurrë. Dhe muri i zjarrit në hostin e tunelit duhet të përcjellë mes ndërfaqes së tunelit dhe LAN-it, dhe ky është hapi që harrohet më shpesh kur një test nga vetë hosti ka sukses.

Nëse operatori nuk mund të shtojë një shërbim, alternativa është një pajisje që mund t'i bashkohet urës, domethënë një laptop ose një ruter që vepron në emër të telefonit. Ky është një shmangie me koston e vet të menaxhimit, jo një konfigurim Android.

Vendosni nga aplikacioni, jo nga tuneli

Pyetni çfarë duhet të arrijë telefoni në të vërtetë, pastaj hartëzojeni. Një ndarje skedarësh ose një sajt intranet i arritshëm me emër ose adresë është një kërkesë IP, dhe një tunel i rrugëzuar e plotëson sapo DNS zgjidh emrin dhe rruga ekziston. Një mjet zbulimi që shfleton domenin lokal të transmetimit nuk është kërkesë IP, dhe asnjë sasi rrugëzimi nuk do ta mbushë.

Ajo tabelë është gjithashtu kërkesa që dërgohet. Emërtoni aplikacionin, adresën ose emrin që përdor, dhe nëse varet nga zbulimi. Një operator mund të veprojë mbi atë përshkrim, gjë që askush nuk mund ta bëjë me një telefon që nuk lidhet.

Së fundi, mbani shërbimin TAP për pajisjet që kanë nevojë për të, në vend që të detyroni çdo klient të imitojë një përshtatës LAN. Dy shërbime me qëllime të qarta mbështeten më lehtë sesa një që funksionon gjysmë për të gjithë.