Android OpenVPN: telefonu rootlamadan özel bir yol eklemek

Bir özel alt ağa daha ihtiyacınız var — diyelim 10.60.0.0/24 — ve profil bunu şu anda içermiyor. Dizüstü bilgisayarda bir yol ekler ve devam ederdiniz. Android'de VPN bir uygulamadır, tun aygıtı o uygulamaya aittir ve root olmadan düzenleyebileceğiniz bir yönlendirme tablosu yoktur. Yol yine de var olmalıdır, ama istemcinin yüklediği profile girer ve ancak karşı taraf kabul ederse çalışır. İşte değişiklik, yeniden bağlanma, sunucu tarafı ve geri alma.

Değişiklikten önce: bir yol ne yapabilir, ne yapamaz

Bir yol tek bir soruyu yanıtlar: bu hedefe giden trafiği hangi arayüz taşımalı. Hiçbir şeye yetki vermez. Ağın sahibi bu telefonun o alt ağa ulaşabileceğini kabul etmediyse, doğru bir yol doğru görünen bir yapılandırma ve ağ geçidinde sessiz bir düşüş üretir; sonraki saati yanlış dosyayı düzenleyerek geçirirsiniz.

Önce o onayı alın, ağın sahibi varsa yazılı olarak. Sonra ne yapmadığınızı not edin: telefona o LAN içinde bir adres vermiyorsunuz, sunucunun dinleyicisini değiştirmiyorsunuz ve siteyi ana makine adına göre seçmiyorsunuz. Bunlar dört farklı değişikliktir ve yalnızca birincisi sizin.

İstemcinin gerçekten yüklediği profili düzenleyin

Sıradan OpenVPN seçenek metnini içe aktaran uyumlu bir istemci için ekleme tek satırdır:

route 10.60.0.0 255.255.255.0

Bunu profilin gövdesine, diğer yönlendirme yönergelerinin yanına ekleyin; işletmenin endpoint, sertifika, anahtar işleme ve doğrulama satırlarını tam olduğu gibi bırakın. Tek satır ödünç almak için baştan sona eski bir örnek yapıştırmayın: sıkıştırma, mutlak dosya yolları ve kullanımdan kalkmış cipher ayarları onunla birlikte gelir ve size ayrı bir hata ayıklama oturumu harcatır.

İnsanların atladığı adım dosyanın sahipliğidir. Uygulama bir profili içe aktardıysa kullandığı kopya uygulamanındır ve indirilen aslı düzenlemek hiçbir şeyi değiştirmez. İstemcinin desteklediği düzenleyiciyi kullanın ya da düzenlenmiş dosyayı güncelleme yolundan yeniden içe aktarın; benzer adlar birden fazlaysa etkin profilin adını doğrulayın. Hangisini değiştirdiğinizi not edin.

Profilde zaten route-nopull varsa sunucudan hiçbir yol kurulmaz ve telefonun ihtiyaç duyduğu her önek açıkça listelenmelidir. Bu meşru bir tasarımdır, ancak atlanan bir satırın sunucunun reddinden farksız görüneceği anlamına gelir.

Yeniden bağlanın ve aygıtta doğrulayın

Önce bağlantıyı kesin, sonra uygulamanın son oturumu geri yüklemesine izin vermek yerine düzenlediğiniz o belirli profile yeniden bağlanın. Bağlantı günlüğünü açın ve istemcinin yeni satırı ayrıştırdığını doğrulayın; arayüzün yok saydığı bir yönlendirme yönergesi yanlış kopyayı düzenlemenin yaygın bir sonucudur.

Hedefi adla değil adresle sınayın. Bilinen bir hizmet bağlantı noktasına TCP denetimi ping'den daha bilgilendiricidir, çünkü birçok ana makine ICMP'ye yanıt verirken hizmet bağlantı noktası süzülür. Adres yanıt verip ad vermiyorsa bu yönlendirme değil çözümleyici sorusudur ve sonraki bölüm size göre değildir.

Buraya iki kapsam denetimi de girer. Uygulama başına VPN, test ettiğiniz uygulama dahil edilen kümenin dışındayken bir adres yolunun bulunabileceği anlamına gelir; bu yüzden gerçekten içeride olan bir uygulamayla test edin. Ayrıca bir IPv4 öneki IPv6 yoluna dair hiçbir şey söylemez; hizmet dual-stack ise ilgili IPv6 yolunu ekleyin ya da istemcinin amaçlamadığınız bir yolu yeğleyeceğini bekleyin.

Olumsuz bir sonucu erken tanımakta yarar var: full-tunnel yol zaten 0.0.0.0/0'ı kapsıyorsa önek eksik değildir ve yeniden eklemek hiçbir şeyi değiştirmez. Yinelenen kapsama, sunucu tarafındaki reddi ya da eksik yanıtı onarmaz.

Yolu sunucuda tamamlayın

Telefonun ötesinde üç şey doğru olmalıdır. Ağ geçidinin hedefe bir yolu ve telefonun kaynağını oraya iletme izni olmalıdır. Hedefin bu kaynağı kabul edip yanıtları ağ geçidinden geri göndermesi gerekir, yoksa tasarımın çıkışta bilinçli bir çeviriye ihtiyacı vardır. OpenVPN kılavuzundaki route seçeneği istemci tarafındaki yönergeyi kapsar; iletme ve dönüş yönlendirmesi ayrı makinelerde ayrı ayarlardır.

Hedef, ağ geçidinin hemen arkasında değil de başka bir VPN istemcisinin arkasındaysa sunucunun o eşin alt ağı için bir iroute'a ihtiyacı vardır. Bu yönerge sunucuya aittir ve hangi istemcinin bir öneke sahip olduğunu açıklar; telefon bunu kendi profilinden sağlayamaz ve istemci tarafındaki hiçbir düzenleme onun yerini tutmaz.

Dönüş yolunu açıkça denetleyin. Tünel yerine varsayılan yoldan çıkan bir yanıt, klasik yarı açık belirtiyi üretir: bağlantı tek yönde kurulur ve hiçbir şey geri gelmez. Hedef geri yönlendiremediğinde ağ geçidinde kaynak çevirisi meşru bir düzeltmedir, ancak kendi sonuçları olan bir ilke kararıdır.

Geri alma ve kabul

Düzenlemeden önce önceki profili saklayın. Değişiklik durumu kötüleştirirse o kopyayı aynı yeniden içe aktarma yolundan geri yükleyin, yeniden bağlanın ve eski davranışın geri geldiğini doğrulayın — bu, değiştirdiğinizi sandığınız şeyi gerçekten değiştirdiğinizi doğrular. Eski durumu geri getirmeyen bir geri alma, uygulamanın bulamadığınız üçüncü bir kopyayı tuttuğu anlamına gelir.

Dört şey geçerli olduğunda değişikliği kabul edin, yeni bir bağlantıdan sonra bu sırayla test ederek: hedef kendi hizmet bağlantı noktasında yanıt veriyor, özel ad bekleniyorsa çözülüyor, HTTPS hâlâ amaçlanan ana makine adını doğruluyor ve yeniden başlatmadan ya da Wi-Fi'den hücresele geçtikten sonra da her şey çalışıyor. Son denetim, yalnızca Android tüneli yeniden kurana kadar var olan bir yolu yakalayan denetimdir.

• Herhangi bir şeyi düzenlemeden önce ağın sahibinin hedefe izin verdiğini doğrulayın.
• Yolu istemcinin yüklediği profile koyun, sonra yeniden içe aktarın ve yeniden bağlanın.
• Doğru adres ailesi için, uygulama başına kapsam içinde, hizmet bağlantı noktasından doğrulayın.
• İletmeyi, dönüş yönlendirmesini ve iroute'u sunucuda düzeltin, telefonda değil.
• Bir geri alma kopyası saklayın ve yeniden başlatmadan sonra yeniden test edin.