OpenVPN redirect-gateway: her bayrağın rotalara ne yaptığı

Profilden redirect-gateway ile bağlanın; makinenizin varsayılan rotası kaybolabilir, ikiye bölünebilir ya da tam olduğu yerde kalabilir, bu kimsenin iki kez okumadığı bayraklara bağlıdır. Seçenek yalnızca yönlendirme durumunu değiştirir, başka hiçbir şeyi değil, bu yüzden ne yaptığına dair tek güvenilir kanıt istemcinin sonradan kurduğu tablodur. Aşağıda bağlantı sonrası tablo, tünelin kendisini ayakta tutan rota ve yönergenin asla kapsadığını iddia etmediği IPv6 trafiği var. Her adım, tünel açıkken istemcide çalıştırabileceğiniz bir komuttur.

Her bayrağın varsayılan rotaya ne yaptığı

Hiç bayrak olmadan seçenek olağan varsayılan rotayı kaldırır ve yerine tüneli koyar, böylece bağlantı açıkken eski ağ geçidi tablodan kaybolur. def1 ekleyin, o varsayılan listede kalır ve işi iki daha dar rota yapar. bypass-dhcp ekleyin, DHCP rotası da yaşar; bu, istemcinin hâlâ yerel DHCP sunucusuna ulaşması gereken bir ağda önemlidir. OpenVPN 2.6 kılavuz sayfasındaki bayrak listesi bir kez okunacak kadar kısadır ve her girdi hangi rotaların tabloya gireceğini değiştirir.

İtilen seçenek geldiğinde aynı şekilde davranır, bu yüzden istemci profilinde hiçbir şey olmayabilir ama tablo tamamen yönlendirilmiş görünür. Bu normaldir: sunucu bayrakları gönderdi, istemci onları uyguladı ve yerel dosya yönergeyi hiç anmadı. İtme hiçbir şey yapmıyor gibi göründüğünde, istemci tarafında çekilen seçenekleri kabul eden ya da atan filtreyi kontrol edin, çünkü atılan seçenek iki tarafta da hata vermez.

def1 varsayılan rotanıza dokunmadan belirginlikle kazanır

İki yarım varsayılan rota birlikte IPv4 uzayını kaplar, 0.0.0.0/1 ve 128.0.0.0/1. Her biri 0.0.0.0/0 adresinden daha belirgindir, bu yüzden arama onları tercih eder, gerçek varsayılan ise en az belirgin eşleşmeyi isteyen her şey için tabloda kalır.

Profili değil tabloyu okuyun, çünkü bu durumlardan hangisinde olduğunuzu yalnızca tablo gösterir. Onları ayırt etmek için iki satır yeterlidir:

ip route show default
ip route show | grep -E '^(0\.0\.0\.0/1|128\.0\.0\.0/1)'

Her satırda yalnızca hedefe değil, arayüze ve metriğe de bakın. Tünele işaret eden varsayılan rota ile tünele işaret eden bir çift yarım varsayılan rota aynı niyeti anlatır ve tünel düştüğünde farklı biçimde başarısız olur, çünkü bir durumda yedek yol hâlâ vardır. İki alanı da değişiklik notuna yazın. Ayakta kalan yedek yol bazen uzak oturumu tüneli onarmaya yetecek kadar uzun süre canlı tutar ve niyet tam tünel olduğunda trafiği sızdıran da odur.

Tünelin uç noktasını erişilebilir tutun

İstemcinin tünelin uzak ucuna, kendisi tünelden geçmeyen bir rotaya ihtiyacı vardır. OpenVPN bu ana bilgisayar rotasını başka bir şeyi değiştirmeden önce kurar ve elle rota düzenleme ya da ikinci bir VPN istemcisi onu kaldırabilir. Sonraki belirti, bağlı olduğunu bildiren ve ardından hiçbir şey geçirmeyen bir bağlantıdır.

Tünel açıkken çekirdeğe uç nokta adresi için hangi arayüzü kullanacağını sorun. Yanıt fiziksel arayüzü ve ağ geçidini adlandırmalıdır, asla tun0 değil:

ip route get 198.51.100.20

Bu arama tünel aygıtını döndürürse, tünel kendi taşımasını taşıyordur ve bir paketin dışarı çıkması gerektiği anda çöker. Yerel önekler, ikinci bağdaştırıcı ve ilke tabanlı yönlendirme burada hâlâ önemlidir, bu yüzden temiz bir dizüstünde çalışan yönlendirme, yönetim arayüzü ve iki varsayılan rotası olan bir ana bilgisayarda başarısız olabilir. Genellikle adres planının yaptığı şey için profil suçlanır.

IPv6 trafiği kendi tablosunu kullanmayı sürdürür

IPv4'ü yönlendirmek IPv6'yı rahat bırakır ve iki aile farklı bayraklarla değiştirilir. Çalışan bir v6 varsayılanı olan çift yığınlı bir ana bilgisayarda v4 trafiği tamamen tünelin içinde kalabilirken v6 yetenekli her hedef fiziksel bağlantıdan çıkar. Bir tabloda doğru görünen ana bilgisayar diğerinde sızdırıyordur.

Bağlandıktan sonra v6 tablosunu kontrol edin, tünelin onu kapsadığını varsaymak yerine. Yönerge adres ailesi bayraklarını tam da bu yüzden taşır ve onları atlayan profil platformun varsayılan olarak yaptığını devralır:

ip -6 route show default
ip -6 route get 2001:db8::10

Bir uygulamanın hangi arayüzü kullandığını kanıtlayın

Bağlı durum bir engel değildir ve rota değişikliği bir acil durdurma anahtarı değildir. Tünel çöktüğünde doğrudan trafik durmak zorundaysa, o ilke güvenlik duvarında yaşar ve kendi testini gerektirir.

Profilin tanımladığı yolu değil, uygulamanın gerçekten izlediği yolu test edin. Önce rotayı sorun, sonra isteği sırayla her arayüze bağlayın ve uzak tarafın ne bildirdiğini karşılaştırın:

ip route get 203.0.113.10
curl -s --interface tun0 https://ifconfig.me
curl -s --interface eth0 https://ifconfig.me

İki istek de aynı adresi döndürürse, yönlendirme tablosu öyle olması gerektiğini söylese de uygulama tüneli kullanmıyordur. Yalnızca tünele bağlı istek başarılı olursa, fiziksel yol o hedef için filtrelenmiştir ve tünel istediğinizi yapıyordur. Bayrakları, kurulu rotaları, uç nokta aramasını ve iki çıkış sonucunu değişiklik kaydına yazın, böylece sonraki kişi ekran görüntüsü yerine olguları devralır.