OpenVPN route-nopull sunucunun neyi göndermesini gerçekten engeller

route-nopull seçeneğini bir istemci profiline, tünelin varsayılan rotanızı yutmasını engellemek için koydunuz ve şimdi ofis alt ağına ulaşılamıyor, oysa istemci hâlâ bağlı görünüyor. Her iki gözlem de doğru ve hiçbir şey bozulmadı. Bayrak, istemciye sunucunun gönderdiği rotaları ve DHCP girdilerini atlamasını söyler; bu, çoğu kişinin onu eklerken beklediğinden daha dar bir talimattır. Geriye kalan ise hangi hedeflerin onu kullanacağına dair hiçbir fikri olmayan, çalışan bir tüneldir.

Bu boşluk, bu yazının konusu olan kararın tamamıdır. Ya ağı sunucu tanımlar ya da istemci tanımlar, ve bayrak bu işi istemciye devreder ama sizin yerinize hiçbir kısmını yapmaz.

Bayrak bağlantı anında neyi devre dışı bırakır

Pulling modundaki bir OpenVPN istemcisi, kimlik doğrulamasından sonra genellikle sunucudan bir paket alır: rotalar, varsayılan ağ geçidinin yönlendirilmesi, DNS sunucuları ve birkaç ince ayar yönergesi. route-nopull etkinken istemci oturumu yine kabul eder, sertifikaları yine doğrular, şifreleri ve keepalive değerlerini yine pazarlık eder ve arayüzü yine ayağa kaldırır. Düşürdüğü şey, gönderilen route satırlarının ve gönderilen dhcp-option satırlarının uygulanmasıdır; DNS dahil.

Karışıklık, ölü bir uygulamanın yanında duran yeşil bir göstergeden gelir. Tünel vardır; hedeflerden o tünele giden eşleme yoktur. İstemci durum panelinde “bağlı ve yönlendiriyor” ile “bağlı ve etkisiz” arasındaki farkı gösteren hiçbir şey yoktur, çünkü tünelin bakış açısından ikisi de aynı durumdur.

Çalışan bir tünel neden hâlâ hiçbir yere yönlendirme yapamaz

Arayüz kendi adresiyle görünür ve noktadan noktaya bir bağlantıda çoğu zaman eşe giden bir ana bilgisayar rotasından daha özel bir şey yoktur. Özel bir alt ağa yalnızca bir rota o arayüzü doğru önekle gösterdiğinde ulaşılabilir ve gönderim devre dışıyken o rota hiçbir zaman gelmez. İndirilen profil de genellikle yardımcı olamaz, çünkü tam olarak bu bilgiyi sunucunun sağlayacağı varsayımıyla yazılmıştır. Arayüzün sağlıklı görünüp alt ağın karanlıkta kalmasının nedeni budur.

Bu yüzden profili okumak çok az şey kanıtlar. Bunun yerine, bağlı makinede çalışan durumu okuyun:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

İkinci komutta alt ağ rotası olmayan bir adres, bu sorunun imzasıdır. Üçüncü komut ise kullanıcıların gerçekten önemsediği soruyu yanıtlar, çünkü kullanmanızı umduğunuz liste yerine çekirdeğin belirli bir hedef için seçeceği arayüzü bildirir. Yanıt fiziksel bağlantınız üzerinden geliyorsa, tünel yolda hiç yoktur.

Ad çözümlemesi ayrı bir nedenden değil, ilgili bir nedenden dolayı başarısız olur. Gönderilen dhcp-option DNS girdileri aynı bayrakla atlanır, bu yüzden iç ana bilgisayarlar için sorgular yerel ağın sağladığı çözümleyiciye gider. O çözümleyicinin ofis için bir bölgesi yoktur, bu nedenle sorgu başarısız olur ya da genel bir yanıt döner, ve hata, istemci yapılandırma sorunu olduğu halde sunucu sorunu gibi görünür. Önce bir adresi, sonra bir adı test etmek ikisini ayıran şeydir.

Bayrak ile önek filtresi arasında seçim yapmak

İki seçenek aynı şikâyetin farklı biçimlerini çözer ve kötü seçim, bağlı ama işe yaramaz durumu üretir. Biri gönderilen politikayı tümüyle değiştirir, diğeri onu öneke göre düzenler. Tablo kısa sürümü verir, ondan sonraki paragraf ise insanları yanıltan kısmı ele alır.

pull-filter üç fiilli bir önek eşleyicisidir, bu yüzden bir satır ailesini kabul edebilir, sessizce yok sayabilir ya da bir önek göründüğünde bağlantıyı tümüyle reddedebilir. Kayda değer olan son davranıştır: bir reddetme kuralı, politika anlaşmazlığını sessiz bir atlamaya değil, başarısız bir el sıkışmaya dönüştürür. OpenVPN 2.6 el kitabı kabul edilen önekleri ve her fiilin tam anlamını listeler.

Yaygın bir orta yol, yalnızca redirect-gateway satırını reddetmek ve ofis rotaları ile DNS'in amaçlandığı gibi gelmesine izin vermektir. Bu, gönderimi sunucunun sizden daha iyi bildiği kısımlar için çalışır durumda tutarken varsayılan rotanızı devralacak tek satırı engeller.

Rotaları ve bir çözümleyiciyi elle eklemek

Bayrağı koruyacaksanız profil, sunucunun söyleyeceğini söylemek zorundadır. İstemci tarafındaki route yönergeleri bağlantı kurulduktan sonra uygulanır, bu yüzden bayrak tarafından engellenmek yerine onunla birlikte çalışırlar. Bunları etkileşimli bir komut satırına değil profile koyun, yoksa bir sonraki yeniden bağlanma çalışan durumu yeniden üretmez.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

DNS satırı garip bir konumdadır: istemci tarafı bir yönergedir, ancak bazı istemciler onu yalnızca platformun DNS entegrasyonu üzerinden uygular ve bağlantı değiştiğinde bu entegrasyon onu ezebilir. systemd çalıştıran bir ana bilgisayarda çözümleyiciyi doğrudan tünel arayüzüne atamak, istemcinin öncelik yarışını kazanmasını ummaktan daha öngörülebilirdir:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Yönlendirme alanı adres kadar önemlidir. O olmadan, genel adlar için sorgular da iç çözümleyiciye gönderilebilir ve özyinelemeyi reddeden herhangi bir iç çözümleyici, özel bölge çalışmaya devam ederken gezinmeyi bozar. Onunla, yalnızca o sonek altındaki adlar tünel çözümleyicisine yönlendirilir, geri kalan her şey fiziksel bağlantıyı izler.

Sonucu denetlemek: adres, ad ve dış yol

Olası hataları üç test ayırır. Özel adresi IP ile alın, sonra aynı ana bilgisayarı adla, sonra sıradan bir genel siteyi. Çalışan bir IP ile başarısız bir ad çözümleyiciyi işaret eder; başarısız bir IP ile çalışan bir ad yönlendirmeyi işaret eder; ikisi de başarısızsa tünel genellikle yolda değildir.

Sonra içeri değil dışarı bakın. Tünel uç noktasının kendi rotası değişiklikten sağ çıkmalıdır ve herhangi bir hata engellemesi uç noktayı yakalamadan tünele kapsamlandırılmalıdır. Tünel düştükten sonra gezinmeye devam eden bir istemci, yönlendirme değil politika sorunudur ve yukarıdaki üç testin hiçbirinde görünmez.

Son listeyi profilin belgelerine yazın: rotalar, çözümleyici, alanlar ve her birinin neden var olduğu. Aynı tabloyu yeniden üreten bir yeniden bağlanma, yerel politikanın eksiksiz olduğunun tek kanıtıdır. Tünel açıkken ve üç test de geçerken uygulamalar hâlâ başarısız oluyorsa, bakılacak bir sonraki yer zaten doğrulanmış sertifikalar değil, bağlı ama çevrimdışı sorunlar sınıfıdır.