route-gateway, redirect-gateway değildir: gerçekte ne değişir
Bu seçenek yalnızca OpenVPN'in kurduğu rotalara bir sonraki atlama noktasını verir. Kaldırılması itilmiş tam tüneli kapatmaz ve düzeltme yönlendirmeye aittir.
Tüneliniz ayağa kalkar, özel alt ağ yanıt verir ve biri profilden ağ geçidi satırını silmiş olsa bile normal gezinme hâlâ VPN'in içinde kaybolur. Bu bileşim, yanlış yönergenin düzenlendiğinin parmak izidir. Kaldırılan şey istemciye kurduğu rotalar için bir sonraki atlama noktasını veriyordu; trafiği yakalamaya devam eden şey başka yerden geldi ve sunucu tarafından itildi. Kapsam ile sonraki atlama ayrı işlerdir ve yalnızca biri genel hedeflerin tüneli kullanıp kullanmadığını belirler.
Kaldırdığınız satır bir sonraki atlamaydı, ilke anahtarı değil
İstemcinin kurduğu her rota, işaret edecek bir ağ geçidi adresine ihtiyaç duyar ve rota kendisi bir tane belirtmediğinde ağ geçidi yönergesi bu adresin kaynağıdır. Onu silin, o rotaların tutunacak yeri kalmaz, bu yüzden ya kurulmazlar ya da hiçbir yere gitmeyen bir yola düşerler. Özel alt ağ tam olarak böyle bir rotanın taşıdığı şeydi.
Bu arada hayatta kalan davranışın başka bir yazarı var: itilmiş bloktaki yönlendirme seçeneği, normal giden trafiği bayraklarına göre tünele taşır. Ağ geçidini kaldırmak onu ne devre dışı bırakır ne zayıflatır. Sonuç iki durumun en kötüsüdür: genel trafik hâlâ yakalanır ve tüneli haklı çıkaran özel hedef artık ulaşılamaz. Bu yüzden aynı ruhla yapılan ikinci düzenleme de hiçbir şeyi değiştirmez.
Dört kol, dört farklı iş
Bu tartışmada dört yönerge birbirinin yerine alıntılanır ve yalnızca biri kapsamı yönetir, yani hangi hedeflerin tünelden geçtiğini. İkincisi rotaların kullandığı sonraki atlamayı belirler, üçüncüsü tek bir önek kurar ve dördüncüsü sunucunun ittiği her şeyi, dağıtımın ihtiyaç duyduğu özel rotalar dahil atar. Tablo onları adlarına göre değil, yöneticinin neyi değiştirmeye çalıştığına göre sıralar, çünkü karışıklığa neden olan şey adlardır. Onları dört ayrı karar olarak ele alın ve gerçekten geri almak istediğinizi seçin.
Uygulamada dördü de çoğu zaman tek bir itilmiş blokta, satır satır gelir ve bu onları tek bir ayarın parçaları gibi gösterir. Öyle değiller ve OpenVPN başvurusu onları tam da bu yüzden ayrı mekanizmalar olarak belgeler. Hangi kararı geri aldığınızı bulmak iştir; düzenleme tek satırdır.
| What you are trying to change | Directive that decides it | What it leaves alone |
|---|---|---|
| Which destinations use the tunnel | redirect-gateway | Per-prefix routes and resolver choice |
| The next hop a pushed route points at | route-gateway | Coverage of public destinations |
| One reachable prefix | route | Every other destination, default path included |
| All pushed routing and DNS at once | route-nopull | Nothing, which is the problem |
İtilmiş satırı filtreleyin, sonraki atlamayı koruyun
İtiraz ettiğiniz kapsam itilmiş bir seçenek olarak geliyorsa dar yanıt, o seçeneği adıyla yok saymak ve itilmiş bloğun geri kalanını dokunulmadan bırakmaktır. Filtre olarak yazıldığında aşağıdaki satıra benzer ve yeri etkilenen istemcinin profilindedir, sunucu yapılandırmasında değil.
pull-filter ignore "redirect-gateway"
Darlık asıl meseledir. Filtre bir metin öneki karşılaştırdığı için daha kısa bir desen sonraki atlama yönergesine de uyar, bu da özel rotaların bağlı olduğu bilgiyi tam olarak sıyırır ve özgün hatayı yeni bir kılıkta tekrarlar. Filtre ayrıca yalnızca itilmiş seçenekler üzerinde çalışır, bu yüzden yerel olarak yazılmış veya bir ağ yöneticisi tarafından dayatılmış eşdeğer bir satıra asla dokunmaz. Ardından yeniden bağlanın, çünkü canlı oturum sunucunun ittiğini yeniden değerlendirmez.
Tabloyu değil, aramayı okuyun
Profili yeniden yükledikten sonra çekirdeğe iki hedefin gerçekte nereye gideceğini sorun: biri özel önekin içinde, biri genel internette. Ana tablonun tam dökümü okuması daha zor ve yanlış okunması daha kolaydır, çünkü bir rota var olup yine de daha belirli bir eşleşmeye kaybedebilir. İlke tabanlı yönlendirmede kural, tablo ve kaynak adres de denetimin parçasıdır.
ip route get 10.40.7.25
ip route get 203.0.113.77
ip rule show
def1 varyantı bilinmeye değer, çünkü eski varsayılan girdiyi görünür bırakırken bir çift yarı-varsayılan aramayı kazanır. Bu yüzden çıktıdaki 0.0.0.0/0 satırı tek başına hiçbir şeyi kanıtlamaz. Arama, listenin yalnızca yanıtladığı görünen soruyu yanıtlar.
DNS, IPv6 ve özel rota hâlâ çalışmalı
Bir IPv4 yönlendirmesini reddetmek çözümleyici hakkında hiçbir şey söylemez, bu yüzden itilmiş DNS seçeneği rotalar doğru görünürken sorguları tünele göndermeye devam edebilir. IPv6 varsayılanı, IPv4 denetiminin hiç dokunmadığı bir adres ailesi için aynısını yapabilir. İkisi de varsayım yerine açık bir karar gerektirir. Ardından özel hizmetin hâlâ yanıt verdiğini doğrulayın, çünkü özel rotasını kaybeden bölünmüş tünel bölünmüş tünel değildir, bozuktur.
Daha geniş bir araç uyarıyı hak eder: route-nopull itilmiş her rotayı ve itilmiş her DNS seçeneğini atar, bu da tam tüneli kesinlikle durdurur ve dağıtımın bağlı olduğu özel rotaları aynı kesinlikle bozar, yani tek bir seçeneğe yönelmiş ad filtresinden çok daha büyük bir çekiçtir. Her değişiklikten sonra özel hedefi, genel hedefi ve çözümleyiciyi kontrol edin ve tamamlanmış el sıkışmayı el sıkışmadan başka hiçbir şeyin kanıtı saymayın.