Sabit OpenVPN adresleri kaynak IP'ye değil kimliğe göre belirlenmeli

'Bu dizüstü bilgisayar 10.90.0.10 alır' diyen adres planları aslında kimlik beyanlarıdır: hangi doğrulanmış cihazın o adresi tutabileceğini söylerler. O cihazın mevcut genel IP'sinin bununla neredeyse hiçbir ilgisi yoktur, çünkü NAT ve dolaşım, kullanıcının kim olduğunu değiştirmeden bu IP'yi değiştirir. Planı kaynak adres üzerine kurmak, ilk otel ağında bozulan kurallar üretir. Planı doğrulanmış kimlik üzerine kurmak, seyahate dayanan bir plan üretir.

Sunucunun doğrulayabildiği şeyden başlayın, sonra adresin ne için olduğuna karar verin.

Kimlik anahtarını adresten önce seçin

Cihaz başına ayrı bir istemci sertifikası, sunucuya her üye için sabit ve doğrulanabilir bir anahtar verir; bu, sabit bir atama için en temiz temeldir. Kullanıcı başına kimlik doğrulama kullanan bir kurulum bunun yerine kullanıcı adını anahtar olarak alabilir, yeter ki yapılandırma seçimi aynı alanı izlesin. İki modeli karıştırmak, bir istemci için sertifikayla ve bir başkası için kullanıcı adıyla eşleşen atamalar üretir ve hangisinin kazanacağını kimse tahmin edemez. Tek bir rezervasyon yazmadan önce planın hangi anahtarı kullandığına karar verin.

duplicate-cn ile aynı anda birkaç oturum aynı ortak adı sunabilir, bu yüzden tek bir sabitlenmiş adres onları tek tek tanımlayamaz. Bu, kimlik modelinin bir özelliğidir; daha iyi bir adres planının düzeltebileceği bir şey değildir.

Adresleri dinamik aralığın dışında ayırın

10.90.0.0/24 gibi subnet topolojili bir ağda düşük adresleri adlandırılmış üyeler için tutun ve dinamik havuzu ayrık bir aralığa koyun. Sabitlenmiş bir üye için atama, sunucunun o kimlik için seçtiği dosyada ifconfig-push 10.90.0.10 255.255.255.0 gibi görünür. İkinci bağımsız değişken net30 altında farklı bir anlam taşır, bu yüzden örnek topolojiye göre nötr değildir. Kopyalamadan önce topolojiyi okuyun.

Havuz kalıcılığı son kiralamaları kaydeder ve genellikle aynı adresi geri verir; bu bir rezervasyon değil bir kolaylıktır. Kalıcılık dosyasının sahiplik kaydı olmasına izin vermeyin, çünkü politika ile değil bağlantı geçmişi ile değişir.

Atama önceliği kimin kazanacağını belirler

Kılavuz bir sıra belgeler: client-connect sırasında üretilen açık bir atama, bir client-config-dir girdisinden önce etkili olabilir; bu girdi de olağan havuz tahsisinden önce gelir. Bu sıralama, 'sabitlenmiş adres uygulanmadı' bildirimlerinin çoğunu açıklar. Aynı zamanda, oturum başına yapılandırma yazan dinamik bir ayırıcının, yetkili sandığınız sabit bir dosyayı sessizce geçersiz kılabileceği anlamına gelir.

Atamaların sahibi olarak tek bir katman seçin ve diğerlerini salt okunur yapın. Her ikisi de karar verme hakkı talep eden iki katman, zamana bağlı atamalar üretir.

Dinamik bir ayırıcı aynı modele ihtiyaç duyar

Oturum başına adres dağıtan bir client-connect entegrasyonu, olağan ayırıcı sorunlarına sahip küçük bir ayırıcıdır. İsteği yapan kimliği doğrulamalı, bir adresi atomik olarak ayırmalı, yalnızca desteklenen bağlantı başına çıktıyı üretmeli ve bağlantı kesildiğinde veya hata olduğunda rezervasyonu bırakmalıdır. Eşzamanlı istekler okuma-sonra-yazma sırası değil, bir kilit veya veritabanı kısıtı gerektirir. Temizlik olmadan havuz, yeniden başlatmaya kadar adres sızdırır.

Ayırıcının durumunu bir sonraki operatörün okuyabileceği yerde tutun ve yalnızca adresi değil, kimlikten adrese verilen kararı da günlüğe yazın.

Adresin politika mı kolaylık mı olduğuna karar verin

Bir güvenlik duvarı kuralı veya rota tek bir tünel adresinden gelen trafiğe izin veriyorsa, o adres erişim politikasına katılır ve yeniden atama o izni devralır. Kimlik, adres ve güvenlik duvarı yaşam döngüsünü koordine edin veya kuralı yeniden atanamayan bir şeye bağlayın. Sabit adresleme yapılandırmayı okunur kılar; kimlik doğrulamanın yerini almaz.

Planı her girdinin bir sahibi olduğu bir envanter olarak yazın, sonra bir cihaz kullanımdan çıkarıldığında gözden geçirin. Kazara yeniden kullanılan rezervasyon, kullanılmayan rezervasyondur.