TAP o TUN? Mga OpenVPN client sa Android at mga server na may tulay

Ang isang profile na gumagana sa laptop ay nabibigo sa telepono. Ang halatang hakbang ay baguhin ang isang salita sa configuration ng client. Hindi makakatulong ang salitang iyon, dahil hindi magkaparehong uri ng trapiko ang pinag-uusapan ng dalawang dulo.

Nagdadala ang TAP ng mga Ethernet frame. Nagdadala ang TUN ng mga IP packet. Ang isang Android VPN app ay binibigyan ng IP interface, na ginagawang posible ang isa sa dalawang kaayusan at hindi ang isa pa, anuman ang sabihin ng configuration.

Maikli ang paghahambing, ngunit ito ang nagpapasya kung maaayos mo ito sa telepono o kailangang baguhin ang serbisyo.

Dalawang uri ng tunnel na may magkaibang payload

Ang TAP interface ay kumikilos tulad ng Ethernet adapter. Nagdadala ito ng mga frame, ibig sabihin ARP, broadcast at lahat ng iba pang dinadala ng LAN sa ilalim ng IP. Ito ang nagpapaging posible ng pagtutulay: pinalalawak ng tunnel ang isang broadcast domain at ang mga client ay kumikilos na parang nakasaksak sa isang switch.

Ang TUN interface ay nagdadala ng mga IP packet na naka-address dito. Walang link layer na makikipag-ayos, walang ARP at walang broadcast. Ang routing ang nagpapasya kung ano ang pumapasok sa tunnel, at ang configuration sa panig ng server ay gumagamit ng subnet sa halip na tulay.

Dapat magkasundo ang dalawang dulo kung alin sa dalawa ang ginagawa nila. Ang pagpapalit ng dev tap sa dev tun sa isang panig ay hindi nagko-convert ng serbisyo; gumagawa ito ng client na umaasa ng routed tunnel at server na nagpapadala pa rin ng frame, at maaaring magtagumpay ang handshake habang walang kapaki-pakinabang na dumadaan.

Ano ang talagang ibinibigay ng Android sa app

Ang VpnService API ng platform ay nagbibigay sa app ng virtual interface para sa mga IP packet, na naka-configure sa mga address, ruta at MTU. Walang Ethernet adapter sa API na iyon, at walang paraan para sa app na mag-imbento ng isa.

Kaya dokumentado ng OpenVPN Connect ang suporta para sa mga routed TUN connection sa Android sa halip na TAP bridging. Ang FAQ ng Android ang pahayag sa panig ng client tungkol sa hangganang ito, at tumutugma ito sa API ng platform.

Ang mga tool sa network na may root, custom firmware o produktong nagpapatupad ng tahasang translation layer ay ibang kaayusan. Ang karaniwang kaso ang dapat planuhan: isang app na makakapag-import ng iyong file at tumatakbo bilang normal na user, may IP interface at walang anuman sa ilalim nito.

Paano ito lumalabas kapag sinubukan mo pa rin

Kadalasang nagtatagumpay ang koneksyon. Ito ang nagpapagulo sa pagkabigo: iniuulat ng client na konektado, nagpapakita ang log ng server ng peer, at walang application na gumagana.

Hindi dumarating ang trapikong naka-address sa itinalagang address ng telepono, dahil itinutulay ng server ang mga frame patungo sa MAC address na hindi kailanman nagkaroon ang telepono. Nananatiling walang laman ang pagtuklas na umaasa sa broadcast. Kung ang LAN ay umaasa sa DHCP sa tulay, hindi makakakuha ng lease ang telepono sa ganoong paraan, at ang manu-manong itinalagang address sa nakatulay na subnet ay hindi pa rin lumilikha ng nawawalang interface.

Ang ilang client ay nabibigo nang mas maaga, sa pag-import ng profile, kapag nakakita sila ng uri ng device na hindi nila maipatupad. Ang dalawang pag-uugali ay pareho ang ibig sabihin, at wala sa kanila ang naaayos sa pamamagitan ng pagdaragdag ng ruta, pagbabago ng DNS o pagpapalawak ng hanay ng address ng tunnel.

Ano ang dapat baguhin ng panig ng server

Ang pagwawasto ay pag-aari ng nagpapatakbo ng serbisyong VPN, at karaniwan itong dagdag sa halip na migrasyon. Magpatakbo ng pangalawang instance ng OpenVPN na may routed device, sariling subnet ng client at configuration sa panig ng server na nagbibigay ng address at nagtutulak ng mga rutang kailangan ng mga telepono. Ang umiiral na nakatulay na instance ay patuloy na naglilingkod sa mga device na talagang nangangailangan ng Ethernet.

Dalawang detalye ang nagpapagana nito sa praktika. Ang LAN ay nangangailangan ng return route para sa bagong subnet ng client, na nakaturo sa host ng VPN, kung hindi ay hindi na babalik ang mga sagot. At ang firewall sa host ng tunnel ay dapat mag-forward sa pagitan ng tunnel interface at LAN, at ito ang hakbang na pinakamadalas makaligtaan kapag nagtagumpay ang pagsubok mula sa host mismo.

Kung hindi maidaragdag ng operator ang isang serbisyo, ang alternatibo ay isang device na makakasali sa tulay, ibig sabihin laptop o router na kumikilos sa ngalan ng telepono. Iyon ay isang likong solusyon na may sariling gastos sa pamamahala, hindi configuration ng Android.

Magpasya mula sa application, hindi sa tunnel

Itanong kung ano ang talagang kailangang maabot ng telepono, pagkatapos ay i-map ito. Ang file sharing o intranet site na naaabot sa pamamagitan ng pangalan o address ay isang pangangailangan sa IP, at sinasapatan ito ng routed tunnel kapag naresolba ng DNS ang pangalan at umiiral ang ruta. Ang tool sa pagtuklas na nagba-browse sa lokal na broadcast domain ay hindi pangangailangan sa IP, at walang dami ng routing ang makakapuno nito.

Ang talahanayang iyon ay ang kahilingang ipapadala rin. Pangalanan ang application, ang address o pangalang ginagamit nito, at kung umaasa ito sa pagtuklas. Makakagalaw ang operator sa paglalarawang iyon, na walang sinuman ang makakagawa sa isang teleponong hindi kumokonekta.

Sa huli, panatilihin ang serbisyong TAP para sa mga device na nangangailangan nito sa halip na pilitin ang bawat client na gayahin ang LAN adapter. Ang dalawang serbisyong may malinaw na layunin ay mas madaling suportahan kaysa isang kalahating gumagana para sa lahat.