bypass-dhcp bir OpenVPN yol planına gerçekte ne ekler
Bu bayrak, tünelin dışındaki bir DHCP sunucusuna tek bir ana bilgisayar yolu kurar. İnternet yönlendirmesi, DNS ilkesi, IPv6 kapsamı veya mobil ağ düzeltmesi değildir.
redirect-gateway def1 bypass-dhcp taşıyan bir profil, IPv4 varsayılan yolunun değiştirilmesini tek bir dar istisnayla birleştirir. İnsanlar son kelimeyi okur ve mobil bağlantılar için genel bir çözüm bekler, sonra bu bayrağın hiçbir zaman desteklemediği bir DHCP teorisiyle öğleden sonrayı geçirir. Her parça tek bir iş yapar ve istisna itibarından çok daha küçüktür.
Yalnızca mobil ağda ortaya çıkan bir arızayı adres atamasına yüklemeden önce bayrakları ayırın. Bu dizenin iki yarısının birbiriyle hiçbir ilgisi yoktur.
İki bayrak, iki ilgisiz iş
def1 ile istemci, zaten var olan varsayılan yolu değiştirmek yerine iki IPv4 yarım varsayılan yolu ekler. 0.0.0.0/1 adres uzayının alt yarısını, 128.0.0.0/1 ise üst yarısını kapsar; böylece birlikte her hedefe ulaşırken her biri 0.0.0.0/0 adresinden daha belirgin kalır. Bu nedenle özgün varsayılan yol, o aramaları kazanmadan tabloda kalır; bu da eski ağ geçidini istemcinin açıkça yönlendirdiği her şey için ulaşılabilir tutar. Ayrıca tabloda üst üste binen iki varsayılan yol bırakır, bu yüzden bir yol dökümü profilin ima ettiğinden daha tuhaf görünebilir.
bypass-dhcp ayrıdır ve varsayılan yola hiç dokunmaz. OpenVPN 2.6 kılavuzu bunu yerel alt ağda olmayan bir DHCP sunucusuna doğrudan yol eklemek olarak açıklar, böylece kiralama trafiği tünelin dışına çıkar, ve bu davranışın Windows istemcilerinde uygulandığını, başka yerlerde bulunmayabileceğini belirtir.
Var olma nedeni mekaniktir. Yarım varsayılan yollar giden trafiği yakaladığında, fiziksel ağdaki bir sunucuya yönelen DHCP yenilemesi, bir şey o adresi gerçek arayüze sabitlemedikçe tünele yönlendirilirdi. Bayrak onu sabitler.
İstisna gerçekte neyi kapsıyor
Başarılı bir bağlantıdan sonraki örnek bir tablo şekli gösterir: tünelden geçen iki yarım varsayılan yol ve fiziksel ağ geçidinden DHCP sunucusuna bir ana bilgisayar yolu. Bunu kendi adresleriniz olarak değil, bir şekil olarak okuyun.
0.0.0.0/1 via 10.8.0.1 dev tun0
128.0.0.0/1 via 10.8.0.1 dev tun0
192.168.1.1/32 via 192.168.1.254 dev wlan0Üçüncü satır tek bir hedefi adlandırır. Bu bir çözümleyici ayarı değil, yerel ağ için genel bir izin değil ve sunucuda bir çıkış kuralı değildir. Hücresel bir operatördeki telefonun, istemcinin bu şekilde tanımlayabileceği bir DHCP sunucusu olmayabilir, bu yüzden bayrak orada hiçbir şeyi değiştirmez.
İstemcinin gerçekte ne kurduğunu kontrol edin
Profilden yazılmış bir seçeneği, sunucunun sunduğu bir seçeneği ve bağlantı sahibinin gerçekten uyguladığı bir yolu ayırt edin. Desteklenmeyen bir bayrağı reddeden istemci yapılandırmanın geri kalanını koruyabilir, böylece tünel açılır ve istisna yalnızca yoktur. Dosyadaki satırın yürürlüğe girdiğini varsaymak yerine istemcinin kendi günlüğünü ve ortaya çıkan yönlendirme tablosunu okuyun. Bunlardan üçü aynı anda doğru olabilir ve paketlerin gerçekte nereye gittiğini yalnızca sonuncusu değiştirir.
VPN uç noktasına giden yolu da aynı anda kullanılabilir tutun. Bu uç nokta istisnası, DHCP istisnasından farklı bir gereksinimdir ve o olmadan tünel onu ayakta tutan taşımayı yakalayabilir.
Bir uygulama hedefi için, başarısız olduğu bağlamda etkin aramayı inceleyin. Daha belirgin yerel yollar, ilke tabanlı yönlendirme ve uygulama başına hariç tutmalar yanıtı değiştirir, bu yüzden iki yarım varsayılan yolun varlığı her akışın envanteri değildir.
Yolun geri kalanı bu bayrakta değil
Sunucunun hâlâ istemcinin internet trafiğini iletme iznine ve onu geri gönderebilen bir çıkış düzenine ihtiyacı vardır. İstemci tarafındaki hiçbir yol, sunucuda eksik yönlendirme veya kaynak çevirisi yaratmaz ve hiçbir bayrak çalışan bir dönüş yolunun yerini tutmaz.
Ad çözümlemesi ve IPv6 her biri kendi ilkesine ihtiyaç duyar. IPv4 değiştirmesi çözümleyiciyi tünel tarafındaki bir sunucuya yöneltmez ve IPv6 kapsamı kurmaz; yalnızca v4'ü yeniden yönlendiren istemci v6 yolunu dokunulmadan bırakır.
Profil ve hedef sabitken, onaylanmış zararsız bir isteği çalışan ve başarısız erişim yolu üzerinde karşılaştırın. Farkın ad çözümlemesinde, tünel kurulumunda, yol seçiminde mi yoksa iletilen trafikte mi olduğunu kaydedin ve yanıtı profille birlikte saklayın. O kayıt, bir sonraki kişinin ulaşamayacağı bir sorun için DHCP'yi suçlamasını engeller.