Tek bir OpenVPN istemcisinde iki hizmet adresi: iroute ve lo

Uygulama tünel adresinde yanıt verir, ancak onun için belgelediğiniz adres hiçbir yere gitmez. OpenVPN günlüğünde hiçbir şey şikayet etmez, eş bağlı görünür ve hub tam olarak bir istemci listeler. Boşluk şudur: bir istemcideki ikinci adres iki ayrı gerçektir; ana makine ona sahip olmalıdır ve hub hangi eşin sahip olduğunu bilmelidir. Birini diğeri olmadan ele alın, trafik ya hub’da ölür ya da eve dönüş yolu olmadan gelir.

Takma ad yereldir, sahiplik uzaktadır

Tünel adresi üzerinde anlaşılır, bu yüzden her iki uç da onu el sıkışma sırasında öğrenir. Ek hizmet adresi hiç müzakere edilmez, bu yüzden onu eklemek hub’da kendi başına hiçbir şeyi değiştirmez. İstemci adrese hemen sahip olabilir ve sunucu bu trafiği yine varsayılan yoluna gönderir ya da düşürür. İki kayıt, iki farklı yerde oluşturulmalıdır.

İstemcide adres ana makineye aittir ve loopback, fiziksel bir bağlantıda asla görünmemesi gereken hizmet kimliği için doğal evdir. Hub’da eş-önek eşlemesi yalnızca sunucunun okuduğu ayrı bir bildirimdir. Kayıtların hiçbiri diğerini gerektirmez.

İki aralığı notlarınızda da ayrı tutun. Bir örnekteki adresler belgeleme değerleridir ve bunları gerçek bir LAN ile çakıştırmak, çalışan bir kurulumu bozuk göstermenin en hızlı yoludur.

Adresi istemciye kalıcı olarak ekleyin

Hizmet adresini ana makine önekiyle loopback’e yerleştirin; böylece ana makine onu ulaşılacak bir alt ağ değil, yerel girdi olarak görür. ip address add 10.66.0.10/32 dev lo bunu bir adres için yapar ve komutu ikinci bir adres için yinelemek iki hizmeti modeller.

Bunu tek seferlik bir test olarak çalıştırın, sonra ana makinenin ağ yapılandırmasına sahip olan şeye taşıyın; çünkü çalışma zamanı eklemesi yeniden başlatmada kaybolur ve yeniden bağlanmalar arasında kopyalar birikir. Ağdan sonra sıralanan bir systemd birimi bir seçenektir ve dağıtımın ağ yöneticisi bir başkasıdır. Hangisini seçerseniz seçin, adres uygulama bağlanmadan önce var olmalıdır, yoksa hizmet yanlış sokette açılır. Elle verilen komuttan sonra değil, yeniden başlatmadan sonra ip address show dev lo ile doğrulayın.

Bağlama, adreslemeden ayrı bir karardır. Her adreste dinleyen bir uygulama, hiç amaçlamadığınız arayüzlerde trafik kabul eder, bu yüzden onu belirli hizmet adresine yönlendirin. O zaman yerel girdi ilkesinin tam olarak eşleştireceği bir şey olur.

Hub’ın gerçekten okuduğu CCD dosyasında talep edin

Sunucuda sahiplik bildirimi, kimliği doğrulanmış ortak ad tarafından seçilen istemci başına dosyaya girer, client-config-dir tarafından adlandırılan dizinin içinde. Satır iroute 10.66.0.10 255.255.255.255, her adres için bir tane, ve sunucuya o hedef için hangi eşin trafik alması gerektiğini söyler.

İki ayrıntı bunu sessizce bozar. Dosya adı, sunucunun gerçekten kullandığı adla eşleşmelidir; bu, username-as-common-name işin içindeyken farklıdır. Ve iroute yalnızca istemci yapılandırma dizini yapılandırılmış TUN modunda etkilidir, bu yüzden aynı satır köprülenmiş bir kurulumda hiçbir şey yapmaz. Var olan dosyaya satır ekleyin, onu değiştirmeyin; çünkü sabit bir adres veya push seçenekleri taşıyor olabilir. OpenVPN 2.6 referansı hem dizini hem de sahiplik yönergesini belgeler.

Hub’ın kendi çekirdeğinin de bu hedeflere bir yola ihtiyacı vardır, böylece yerelde üretilen trafik tünel sürecine girer. Sunucu yapılandırmasındaki route 10.66.0.10 255.255.255.255 sunucunun kendisinin oluşturduğu trafiği kapsar, diğer istemciler ise hedefi kendileri öğrenmek için push "route 10.66.0.10 255.255.255.255"’a ihtiyaç duyar.

Yönlendirme ve yetkilendirme ayrı kalır. İtilen bir rota istemciye paketlerin nereye gönderileceğini söyler ve hiçbir şey vermez; hizmet yine de arayanı kendi koşullarıyla kabul etmelidir.

Girdi ilkesini ve yanıt yolunu kontrol edin

Takma ada adreslenen bir paket, sahip ana makineye yerel girdi olarak ulaşır, bu yüzden soru yerel güvenlik duvarının o kaynağa ve bağlantı noktasına izin verip vermediğidir. Tüm adresi açmak yerine VPN kaynak aralığından belirli hizmet bağlantı noktasına izin verin.

Yanıtların arayana dönüş yoluna ihtiyacı vardır. Normal tünel havuzundaki bir arayan için bu yol zaten vardır, çünkü tünel aygıtı onu taşır. Başka bir yönlendirilmiş ağın arkasındaki arayan, o ağın dönüş rotasına da ihtiyaç duyar ve asimetrik kurulumların paket kaybettiği yer burasıdır.

Aynı bağlantı noktasında farklı bir adrese bağlı ikinci bir dinleyiciye dikkat edin, çünkü çekirdek eşleşen sokete teslim eder ve sonuçlar rastgele görünür. ss -lntp ile kontrol edin ve bağlı adresin hizmet takma adı olduğunu doğrulayın. Kaynak NAT burada gerekli değildir ve onu eklemek günlüklerinizin bağlı olduğu arayan kimliğini gizler.

Adresleri ve sahipliği ayrı ayrı test edin

İki adımda test edin. Önce sahip ana makinenin takma adındaki hizmete kendisinden ulaşabildiğini doğrulayın; bu, bağlama ve güvenlik duvarı sorunlarını yönlendirmeden ayırır. Sonra uygulamanın kendi kimlik doğrulamasını kullanarak gerçek bir VPN arayanından test edin. Birincisi geçip ikincisi başarısız olduğunda, eksik parça hub tarafındadır.

Bağlantıdan sonra da kalan hata modlarını kontrol edin: tünel kapalıyken takma ad atanmış kalır ve eş yokken hub rotasını korur. Hiçbir nesne tek başına hizmetin erişilebilir olduğunu kanıtlamaz, bu yüzden iki adımlı test dizüstü bilgisayardan tek bir ping’i yener.