TAP yoxsa TUN? Android OpenVPN müştəriləri və körpülənmiş serverlər

Noutbukda işləyən profil telefonda uğursuz olur. Aydın addım müştəri konfiqurasiyasında bir sözü dəyişməkdir. Həmin söz kömək etməyəcək, çünki iki tərəf eyni trafik növündən danışmır.

TAP Ethernet kadrlarını daşıyır. TUN IP paketlərini daşıyır. Android VPN tətbiqinə IP interfeysi verilir və bu, konfiqurasiyanın nə dediyindən asılı olmayaraq, iki variantdan birini mümkün, digərini isə qeyri-mümkün edir.

Müqayisə qısadır, lakin bunu telefonda düzəldə biləcəyinizi, yoxsa xidməti dəyişməli olduğunuzu müəyyən edir.

Fərqli yüklər daşıyan iki tunel növü

TAP interfeysi Ethernet adapteri kimi davranır. Kadrları daşıyır, yəni ARP, yayım və LAN-ın IP-dən aşağıda daşıdığı hər şeyi. Körpüləməni məhz bu mümkün edir: tunel yayım domenini genişləndirir və müştərilər özlərini kommutatora qoşulmuş kimi aparır.

TUN interfeysi ona ünvanlanmış IP paketlərini daşıyır. Razılaşdırılacaq kanal qatı, ARP və yayım yoxdur. Tunelə nəyin girəcəyini marşrutlaşdırma həll edir və server konfiqurasiyası körpü əvəzinə altşəbəkə istifadə edir.

Hər iki son nöqtə bunlardan hansını etdikləri barədə razılaşmalıdır. Bir tərəfdə dev tap sözünü dev tun ilə əvəz etmək xidməti çevirmir; nəticədə marşrutlaşdırılmış tunel gözləyən müştəri və hələ də kadr ötürən server yaranır, əl sıxışma uğurlu ola bilər, amma istifadəyə yararlı heç nə keçmir.

Android tətbiqə əslində nə verir

Platformanın VpnService API-si tətbiqə IP paketləri üçün virtual interfeys verir; ünvanlar, marşrutlar və MTU ilə konfiqurasiya olunur. Həmin API-də Ethernet adapteri yoxdur və tətbiqin onu uydurmağının yolu yoxdur.

Buna görə OpenVPN Connect Android-də TAP körpüləməsi yerinə marşrutlaşdırılmış TUN bağlantılarına dəstəyi sənədləşdirir. Android FAQ bu sərhədin müştəri tərəfindəki ifadəsidir və platformanın API-si ilə uyğundur.

Kök şəbəkə alətləri, fərdi proqram təminatı və ya açıq tərcümə qatı tətbiq edən məhsul başqa variantlardır. Planlaşdırma lazım olan adi hal budur: faylınızı idxal edə və adi istifadəçi kimi işləyə bilən tətbiq, IP interfeysi ilə və altında heç nə olmadan.

Yenə də cəhd etdikdə necə görünür

Bağlantı adətən qurulur. Uğursuzluğu çaşdırıcı edən də budur: müştəri bağlı olduğunu bildirir, server jurnalı həmsöhbət göstərir və heç bir tətbiq işləmir.

Telefona təyin edilmiş ünvana göndərilən trafik çatmır, çünki server kadrları telefonun heç vaxt sahib olmadığı MAC ünvanına körpüləyir. Yayımdan asılı kəşf boş qalır. Əgər LAN körpü üzərindən DHCP-yə güvənirsə, telefon bu yolla icarə almır və körpülənmiş altşəbəkədə əl ilə təyin edilmiş ünvan da çatışmayan interfeysi yaratmır.

Bəzi müştərilər daha erkən, profil idxalında, həyata keçirə bilmədikləri cihaz növünü gördükdə uğursuz olur. Hər iki davranış eyni şeyi bildirir və heç biri marşrut əlavə etməklə, DNS-i dəyişməklə və ya tunelin ünvan aralığını genişləndirməklə düzəlmir.

Server tərəfi nəyi dəyişməlidir

Düzəliş VPN xidmətini idarə edən şəxsə aiddir və adətən miqrasiya deyil, əlavədir. Marşrutlaşdırılmış cihazla, öz müştəri altşəbəkəsi ilə və ünvanları təyin edib telefonların ehtiyac duyduğu marşrutları ötürən server konfiqurasiyası ilə ikinci OpenVPN nüsxəsi işlədin. Mövcud körpülənmiş nüsxə Ethernetə həqiqətən ehtiyac duyan cihazlara xidmət etməyə davam edir.

İki detal bunu praktikada işlək edir. LAN yeni müştəri altşəbəkəsi üçün VPN hostuna yönələn dönüş marşrutuna ehtiyac duyur, əks halda cavablar heç vaxt qayıtmaz. Və tunel hostundakı firewall tunel interfeysi ilə LAN arasında yönləndirməlidir; hostun özündən edilən sınaq uğurlu olduqda ən çox gözdən qaçan addım budur.

Əgər operator xidmət əlavə edə bilmirsə, alternativ körpüyə qoşula bilən cihazdır, yəni telefonun adından işləyən noutbuk və ya marşrutlaşdırıcı. Bu, öz idarəetmə xərci olan bir müvəqqəti həll yoludur, Android konfiqurasiyası deyil.

Tuneldən deyil, tətbiqdən qərar verin

Telefonun əslində nəyə çatmalı olduğunu soruşun, sonra onu xəritələyin. Ad və ya ünvanla çatılan fayl paylaşımı və ya intranet saytı IP tələbidir və DNS adı həll edib marşrut mövcud olduqda marşrutlaşdırılmış tunel bunu ödəyir. Yerli yayım domenini gəzən kəşf aləti IP tələbi deyil və heç bir miqdarda marşrutlaşdırma onu doldurmaz.

Həmin cədvəl həm də göndəriləcək sorğudur. Tətbiqi, istifadə etdiyi ünvanı və ya adı və kəşfdən asılı olub-olmadığını göstərin. Operator bu təsvirə əsasən hərəkət edə bilər; heç kim isə qoşulmayan telefonla hərəkət edə bilməz.

Nəhayət, hər müştəriyə LAN adapterini təqlid etdirmək əvəzinə TAP xidmətini ona ehtiyac duyan cihazlar üçün saxlayın. Aydın məqsədləri olan iki xidməti dəstəkləmək, hamı üçün yarımçıq işləyən bir xidmətdən asandır.