Tek bir IPv4 hedefini OpenVPN tünelinin dışına nasıl gönderirsiniz

Çoğu tam tünel yapılandırması her paketi VPN üzerinden gönderir ve redirect-gateway bunu mümkün kılan direktiftir. Tek bir hedef yine de muaf tutulabilir. O adres için net_gateway yer tutucusuyla bir ana bilgisayar rotası eklemek, istemciye makinenin özgün ağ geçidi üzerinden ona ulaşmasını söyler; geri kalan her şey tüneli kullanmaya devam eder.

Satır zararsız görünür ve çoğu zaman öyledir, ancak yalnızca tek bir soruyu çözer: tam o IPv4 adresine giden paketler nereye gider. DNS'i, IPv6'yı, güvenlik duvarı politikasını veya bağlantıyı hangi sürecin açtığını değiştirmez ve bunların her biri muafiyeti sessizce boşa çıkarabilir.

net_gateway aslında neyi adlandırır

Bu muafiyetin profil girdisi tek bir satırdır: route 198.51.100.77 255.255.255.255 net_gateway. İlk adres hedef için bir belge yer tutucusudur, maske onu tek ana bilgisayarlık bir rotaya dönüştürür ve son belirteç ağ geçidi yer tutucusunu adlandırır. OpenVPN rotaları kurarken ağ geçidi yer tutucularını çözer. vpn_gateway tünelin kendi ağ geçidini, yani VPN bağlantısının uzak tarafını belirtir. net_gateway VPN herhangi bir şeyi değiştirmeden önce ana bilgisayarın sahip olduğu varsayılan ağ geçidini belirtir; bu genellikle fiziksel ağdaki yerel yönlendiricidir.

Üçüncü yer tutucu remote_host, VPN sunucusunun adresine atıfta bulunur ve tünelin sunucuya fiziksel yoldan ulaşabilmesi için vardır. Bu üçünü karıştırmak, bir muafiyetin yanlış yere gitmesinin veya hiç kurulmamasının en yaygın nedenidir.

Değer bağlantı anında okunur, dosyaya yazılmaz. Makine başka bir ağa geçerse VPN'den önceki ağ geçidi değişir ve rota yenisini izler. Bu genellikle istediğiniz şeydir, ancak muafiyetin davranışının istemcinin başladığı ağa bağlı olduğu anlamına da gelir.

Bir ana bilgisayar rotası tünelin varsayılanını neden yener

Yönlendirme, en belirgin eşleşen önek tarafından belirlenir. redirect-gateway def1 normalde varsayılan rotayı değiştirmez; iki yarı ekler, adres uzayının alt yarısı için bir rota ve üst yarısı için bir tane, böylece özgün varsayılan rota başka kullanımlar için korunur. Bu yarılar tek bir adresten daha geniştir.

255.255.255.255 maskeli tek adres için bir rota /32'dir ve bu, IPv4'ün ulaşabileceği en yüksek belirginliktir. O adrese giden bir paket değerlendirildiğinde /32 eşleşir ve hangi rotanın önce kurulduğuna bakmaksızın kazanır. Muafiyetin arkasındaki mekanizma budur ve rota gerçekten mevcut olduğu sürece Linux, macOS ve Windows'ta aynı şekilde çalışır.

Windows ikinci bir boyut ekler. İki rota eşit derecede belirgin olduğunda daha düşük metrikli olan kazanır ve bir VPN bağdaştırıcısı sonucu değiştiren bir arabirim metriği taşıyabilir. /32 hâlâ yarılardan daha belirgindir, bu yüzden muafiyet genellikle geçerlidir, ancak önceki oturumdan kalan eski bir rota eşit derecede belirginse kafa karıştırıcı bir sonuç verebilir.

Muafiyetin kapsamadıkları

DNS ilk boşluktur. İstemci iç çözümleyici ayarlarını itebilir ve işletim sistemi bunları sorgular için kullanmaya devam eder. Bağlanmadan önce bir adı çözen uygulama, doğrudan gitmesi gereken bir hizmet için iç adres veya doğru çözülen ama sonra bir sonraki boşluğa takılan dış adres alabilir.

IPv6 ikincisidir. Rota direktifi yalnızca IPv4 ile ilgilenir. Çift yığınlı bir hedef IPv6'yı tercih edebilir; bu, politikaya bağlı olarak tüneli veya ana bilgisayarın IPv6 varsayılan rotasını izler, böylece IPv4 muafiyeti hiçbir zaman yürürlüğe girmez. Eşleşen bir IPv6 rotasına veya o istemci için IPv6'yı devre dışı bırakma konusunda bilinçli bir karara ihtiyacınız var.

Uygulama kapsamı üçüncüsüdür. Kural hedefe dayalıdır, bu yüzden o adrese bağlanan her süreç doğrudan yolu kullanır, aklınızdaki süreç olsun ya da olmasın. Tersine, bir web sitesi birkaç adresten yanıt verebilir, bu yüzden bir /32'yi muaf tutmak siteyi muaf tutmaz. Gerçek gereksinim uygulama başına yönlendirme ise Community istemcisinin rota tablosu yanlış araçtır.

Kendinizi kandırmadan muafiyeti denetlemek

Tarayıcıyla değil, kurulu rotayla başlayın. Linux'ta çekirdeğe belirli adres için hangi rotayı ve sonraki atlamayı kullanacağını sorun; Windows'ta o /32 için rota tablosunu okuyun. Ağ geçidinin tünel değil fiziksel olan olduğunu doğrulayın. Girdi yoksa profil uygulanmamıştır veya istemcinin rotaları değiştirme yetkisi yoktu.

Sonra iki hedefi test edin. Muaf adrese yapılan istek fiziksel arabirimden çıkmalı ve bir iç denetim adresine yapılan istek hâlâ tüneli kullanmalıdır. Yalnızca muaf adresi test etmek tünelin geri kalanı hakkında hiçbir şey kanıtlamaz ve genel bir web sitesini test etmek o sitenin çözüldüğü adresi test eder; bu, kuraldaki adres olmayabilir.

Son olarak rotayı geçersiz kılabilecek denetimleri kontrol edin. İstemci tarafındaki bir kill switch veya Windows'un block-outside-dns ayarı doğrudan trafiği yasaklayabilir; bu, rota doğru olsa bile başarısız olan bir bağlantı olarak görünür. Muafiyet çalışıyor gibi görünsün diye bu denetimleri kapatmayın; politika doğrudan yolu yasaklıyorsa muafiyet, VPN hizmetinin sahibi için bir tasarım sorunudur.

Yeniden bağlandıktan veya ağ değiştikten sonra tekrar kontrol edin, çünkü VPN öncesi ağ geçidi ve kullanılabilir yol profilin değil, o anın özellikleridir.