openfortivpn bağlandığında rotaların ve DNS'in sahibi kim olmalı?

Çalışan bir openfortivpn oturumunda dört aşama üst üste yığılır. İstemci ağ geçidinde kimlik doğrular ve bir TLS bağlantısı başlatır, ardından bu bağlantı içinde PPP çalıştırır, sonra bir adres ve DNS bilgisi alır ve son olarak ana bilgisayar rotalarını ve çözümleyici ayarlarını uygular. Her aşama, bir sonraki canlı olmasa da canlı olabilir; bu yüzden “bağlı” destek başlıklarında bu kadar kaygan bir sözcüktür.

Karışıklığın çoğunu ortadan kaldıran karar, son aşamanın sahibinin kim olduğudur. Ya VPN istemcisi ana bilgisayar değişikliklerini kendisi uygular ya da bunu başka bir bileşen yapar; ikisini yarı yolda karıştırmak, rotaların ve çözümleyici dosyalarının farklı oturumları tanımlamasına yol açar.

Tek bir bağlantı gibi görünen dört aşama

İlk aşama kabuldür. adlandırılmış bir kimlik doğrulama alanı veya tek kullanımlık kod aracılığıyla, devam etmek için gereken parametreleri alır. İstemci ağ geçidine bağlandığını yazdırdığında bu, TLS taşımasının çalıştığı anlamına gelir. PPP'nin anlaştığı anlamına gelmez ve kesinlikle bir iç uygulamanın erişilebilir olduğu anlamına gelmez.

İkinci aşama PPP bağlantısıdır. İstemci tünel aygıtına karşı bir PPP süreci başlatır ve iki taraf bağlantı seçeneklerini ve adresleri müzakere eder. Ancak bundan sonra ana bilgisayar oturumun hangi yerel ve uzak adresleri kullandığını bilir ve ancak o zaman tünele işaret eden bir rota anlam kazanır.

Üçüncü aşama bu bilgiyi ana bilgisayara uygulamaktır ve sahiplik burada önemlidir. İstemci rotaları ekleyip çözümleyici yapılandırmasını yeniden yazabilir ya da geri çekilip her ikisini o makinedeki ağı yöneten başka bir şeye bırakması söylenebilir. Projenin README dosyası bunları tek bir otomatik davranış yerine ayrı sorumluluklar olarak tanımlar.

Yönlendirme tablosunu kim düzenler

Varsayılan olarak sahip istemcidir. Fiziksel arabirim üzerinden ağ geçidine doğru bir rota, tünelin eşi için bir rota ve oturumun kullanmasına izin verilen ağlar için rotalar ekler, ardından süreç çıkarken bunları kaldırır. Bu varsayılan, tek bir ağ yöneticisi olan ve başka VPN yazılımı bulunmayan bir dizüstü bilgisayarda kullanışlıdır.

Devri yalnızca başka bir şey yönlendirmenin gerçek sahibi olduğunda seçin. Bir ağ yöneticisi entegrasyonu, bir kapsayıcı ağ ad alanı veya site genelinde bir yönlendirme aracısı aynı önekleri nasıl kuracağını ve temizleyeceğini zaten biliyor olabilir. no-routes seçeneğini geçmek o zaman iki yazıcının aynı tablo için savaşmasını önler; bu, temiz bir arıza yerine bir alt ağın aralıklı kaybı olarak görünen bir yarıştır.

Örtüşme devretmenin ikinci nedenidir. İtilen rotalar yerel ağın zaten kullandığı bir önek içeriyorsa, istemci çakışmayı sizin için çözemez. Birinin bu öneğe tünelden mi, fiziksel bağlantıdan mı yoksa daha belirli bir rotadan mı ulaşılabileceğine karar vermesi gerekir ve bu karar topolojinin sahibine aittir.

Temizlik üçüncüsüdür. Rotalarını kaldırmadan önce çöken bir istemci, oturumdan daha uzun yaşayan bir kara delik bırakır ve sonraki bağlantı üzerine bir kopya ekleyebilir. Yönlendirmenin sahibi, eski girdilerin gittiğini doğrulamanın da sahibidir. Bu denetimi isteğe bağlı bir temizlik adımı değil, başlangıç yolunun parçası yapın.

DNS'in ve çözümleyici dosyasının sahibi kim

DNS daha keskin kenarlı aynı karardır. İstemci, ağ geçidinin veya PPP eşinin bildirdiği DNS sunucularını kabul edip bunları ana bilgisayarın çözümleyici yapılandırmasına yazabilir. Basit bir makinede tam istediğiniz budur, çünkü iç adlar o zaman yalnızca tünel çalışırken çözülür.

Modern bir Linux ana bilgisayarında çözümleyici yerel bir stub tarafından yönetilebilir ve çözümleyici dosyasını o stub'ın arkasından yeniden yazmak doğru görünen ama tutarsız davranan bir yapılandırma üretir. Ana bilgisayar zaten bir çözümleyici yöneticisi çalıştırıyorsa, DNS'in sahibi o olsun ve tünelin sunucularını desteklenen arabirimi aracılığıyla ona verin. İstemcinin no-dns seçeneği orada doğru seçimdir, bir geçici çözüm değil.

Bölünmüş DNS, dosyayı kimin yazdığından ayrı bir sorudur. Her sorguyu tünelden göndermek basit ve yavaştır; yalnızca iç bölgeleri tünelden göndermek, çoğu basit istemcinin sunmadığı alan başına yapılandırma gerektirir. İstemcinin çözümleyici değişikliklerini etkinleştirmeden önce ana bilgisayarın hangi davranışa ihtiyacı olduğuna karar verin. Buradaki yanlış seçim, tünelin kendisi iyi olsa bile ad çözümleme kesintisi gibi görünür.

Ayrıcalık, hazır olma ve devir

Tünel aygıtını oluşturmak ve ana bilgisayar rotalarını veya çözümleyici durumunu düzenlemek yükseltilmiş ağ yetkisi gerektirir. Yaygın hata, bu nedenle tüneli kullanan tarayıcı veya uygulama da dahil her şeyin root olarak çalışması gerektiği sonucuna varmaktır. Ayrıcalıklı kısmı küçük tutun: istemci ve yapılandırma dosyası bir yöneticiye ait olsun, kullanıcı uygulamaları normal hesaplarını korusun.

Hazır olma tüketici başına tanımlanmalıdır. Bir gözetleyici, istemci süreci çalıştığında ve tünel aygıtı var olduğunda hizmeti başlamış sayabilir. Bir yedekleme işi, VPN'i yalnızca depolama uç noktası tünelden yanıt verdiğinde kullanılabilir saymalıdır. Bunlar farklı denetimlerdir ve daha zayıf olanı daha güçlü amaç için kullanmak çok erken başlayan ve aralıklı başarısız olan işler üretir. Seçilen tanımı yazın, çünkü hazır olma konusunda anlaşamayan bir gözetleyici ve iş, olmayı bekleyen bir destek biletidir.

Sözleşmeyi dört gözlemle test edin: ağ geçidi aşaması tamamlanır, PPP adresleri atar, amaçlanan rota bulunur ve bir iç ana bilgisayara istek başarılı olur. Ardından istemciyi durdurun ve bunların her birinin kaldırıldığını veya geri yüklendiğini doğrulayın. Tünel kapandıktan sonra ana bilgisayar hâlâ iç adları çözüyorsa veya hâlâ bir rota tutuyorsa, sahiplik devri eksiktir.