TAP aŭ TUN? OpenVPN-klientoj por Android kaj pontaj serviloj

Profilo, kiu funkcias sur tekkomputilo, fiaskas sur la telefono. La evidenta paŝo estas ŝanĝi unu vorton en la klienta agordo. Tiu vorto ne helpos, ĉar la du finoj ne parolas pri la sama speco de trafiko.

TAP portas Ethernet-kadrojn. TUN portas IP-paketojn. Android-a VPN-aplikaĵo ricevas IP-interfacon, kio ebligas unu el tiuj du aranĝoj kaj malebligas la alian, sendepende de tio, kion diras la agordo.

La komparo estas mallonga, sed ĝi decidas, ĉu vi povas ripari tion sur la telefono aŭ devas ŝanĝi la servon.

Du specoj de tunelo kun malsamaj utilaj ŝarĝoj

TAP-interfaco kondutas kiel Ethernet-adaptilo. Ĝi portas kadrojn, do ARP, dissendadon kaj ĉion alian, kion LAN portas sub IP. Tio ebligas pontadon: la tunelo etendas dissendan domajnon, kaj klientoj kondutas kvazaŭ ili estus enŝovitaj en ŝaltilon.

TUN-interfaco portas IP-paketojn adresitajn al ĝi. Mankas liga tavolo por intertrakti, mankas ARP kaj mankas dissendado. Enkursigo decidas, kio eniras la tunelon, kaj la servila agordo uzas subreton anstataŭ ponto.

Ambaŭ finoj devas konsenti, kiun el tiuj du ili faras. Ŝanĝi dev tap al dev tun unuflanke ne konvertas la servon; ĝi produktas klienton, kiu atendas enkursigitan tunelon, kaj servilon, kiu ankoraŭ sendas kadrojn, kaj la manpremo povas sukcesi dum nenio uzebla trapasas.

Kion Android efektive donas al la aplikaĵo

La VpnService-API de la platformo donas al aplikaĵo virtualan interfacon por IP-paketoj, agorditan per adresoj, enkursigoj kaj MTU. En tiu API mankas Ethernet-adaptilo, kaj mankas maniero, ke la aplikaĵo elpensu unu.

Tial OpenVPN Connect dokumentas subtenon por enkursigitaj TUN-konektoj sur Android anstataŭ TAP-pontado. La Android-oftaj demandoj estas la klientflanka klarigo pri tiu limo, kaj ĝi kongruas kun la platforma API.

Retaj iloj kun radikaj rajtoj, propra firmaro aŭ produkto, kiu efektivigas eksplicitan tradukan tavolon, estas aliaj aranĝoj. La ordinara kazo estas tiu, pri kiu indas plani: aplikaĵo, kiu povas importi vian dosieron kaj funkcii kiel ordinara uzanto, kun IP-interfaco kaj nenio sub ĝi.

Kiel ĝi aspektas, kiam vi tamen provas

La konekto kutime establiĝas. Tio igas la fiaskon konfuza: la kliento raportas konekton, la servila protokolo montras kunulon, kaj neniu aplikaĵo funkcias.

Trafiko adresita al la atribuita adreso de la telefono ne alvenas, ĉar la servilo pontas kadrojn al MAC-adreso, kiun la telefono neniam havis. Dissendad-dependa malkovrado restas malplena. Se la LAN dependas de DHCP trans la ponto, la telefono tiel ne ricevos luon, kaj permane atribuita adreso en la pontita subreto ankoraŭ ne kreas la mankan interfacon.

Iuj klientoj fiaskas pli frue, ĉe la importo de la profilo, kiam ili vidas specon de aparato, kiun ili ne povas efektivigi. Ambaŭ kondutoj signifas la samon, kaj neniu el ili ripariĝas per aldonado de enkursigoj, ŝanĝo de DNS aŭ larĝigo de la adresa gamo de la tunelo.

Kion devas ŝanĝi la servila flanko

La riparo apartenas al tiu, kiu funkciigas la VPN-servon, kaj ĝi kutime estas aldono, ne migrado. Lanĉu duan OpenVPN-instancon kun enkursigita aparato, propra klienta subreto kaj servila agordo, kiu atribuas adresojn kaj puŝas la enkursigojn, kiujn la telefonoj bezonas. La ekzistanta pontita instanco daŭre servas la aparatojn, kiuj vere bezonas Ethernet.

Du detaloj igas tion funkcii en praktiko. La LAN bezonas revenan enkursigon por la nova klienta subreto, montrantan al la VPN-gastiganto, alie respondoj neniam revenos. Kaj la fajroŝirmilo sur la tunela gastiganto devas plusendi inter la tunela interfaco kaj la LAN, kaj tio estas la paŝo plej ofte preterlasata, kiam testado de la gastiganto mem sukcesas.

Se la administranto ne povas aldoni servon, la alternativo estas aparato, kiu povas aliĝi al la ponto, do tekkomputilo aŭ enkursigilo aganta nome de la telefono. Tio estas provizora solvo kun propra administra kosto, ne Android-agordo.

Decidu laŭ la aplikaĵo, ne laŭ la tunelo

Demandu, kion la telefono efektive devas atingi, poste mapu tion. Dosierpartigo aŭ intraneta retejo atingebla per nomo aŭ adreso estas IP-postulo, kaj enkursigita tunelo kontentigas ĝin, post kiam DNS solvas la nomon kaj la enkursigo ekzistas. Malkovrilo, kiu traserĉas la lokan dissendan domajnon, ne estas IP-postulo, kaj neniu kvanto da enkursigado plenigos ĝin.

Tiu tabelo estas ankaŭ la peto, kiun vi sendu. Nomu la aplikaĵon, la adreson aŭ nomon, kiun ĝi uzas, kaj ĉu ĝi dependas de malkovrado. Administranto povas agi laŭ tiu priskribo, kion neniu povas fari laŭ telefono, kiu ne konektiĝas.

Fine, konservu la TAP-servon por la aparatoj, kiuj bezonas ĝin, anstataŭ igi ĉiun klienton imiti LAN-adaptilon. Du servoj kun klaraj celoj estas pli facile subteneblaj ol unu, kiu duone funkcias por ĉiuj.