OpenVPN sunucusu nopool ile: açık bir havuz aralığı bildirin

Sunucu yardımcıları bir alt ağ yapılandırır ve ardından onu kendi seçtikleri dinamik bir havuzla doldurur. Bu varsayılan, bazı adreslerin dağıtım dışında kalması gerekene kadar kullanışlıdır — ister sabit atamalar için ayrılmış olsunlar ister gelecekteki bir bölüm için tutulsunlar. Otomatik havuzu bastırmak ve aralığı kendiniz bildirmek iki satır ve hangi adreslerin dağıtım için olmadığına dair tek bir bilinçli karar gerektirir. Geri kalanı operasyonel disiplindir: envanter, uygulama, doğrulama, geri alma.

Bu, çalışan bir hizmette değişikliktir, bu yüzden operasyonel bir görev olarak ele alın: önce envanter, sonra normal yaşam döngüsüyle uygulama, yeni bir istemciyle doğrulama ve hazır bir geri alma.

Zaten sahip olduğunuz alt ağdan başlayın

Geçerli sunucu yapılandırmasını ve istemcilerin gerçekte tuttuğu adresleri okuyun. Havuz değişikliği ancak o tabana göre anlamlıdır ve taban her zaman dosyanın ima ettiği şey değildir, çünkü yönetilen bir ürün veya yapılandırma üreteci okuduğunuz dosyanın sahibi olabilir.

grep -nE '^(topology|server|ifconfig-pool|max-clients|client-config-dir)' /etc/openvpn/server/lab.conf
ip -4 addr show tun0

Yürürlükteki topolojiyi doğrulayın. Alt ağ topolojisinde her istemci havuzdan bir adres alır; eski net30 düzenleri istemci başına küçük bir blok ayırır ve aritmetik tamamen farklıdır. Sunucu hâlâ net30 üzerindeyse bu sayfa yanlış geçiş kılavuzudur ve havuz numaraları beklediğiniz anlamı taşımaz. Adres aritmetiğini başka bir yerden kopyalamadan önce o satırı denetleyin.

Sunucunun kendi adresini, istemci yapılandırma dizinindeki her sabit atamayı ve bir yolun veya erişim kuralının bağlı olduğu her adresi yazın. Dinamik aralığın dışında kalması gereken adresler bunlardır. Bunları önce yazmak aralığı tahmin değil karar yapar. Geri almaya da geri yüklenecek somut bir şey verir.

nopool ekleyin ve aralığı bildirin

Yardımcı anahtar sözcük nopool kabul eder; bu, alt ağ yapılandırmasını korur ve otomatik dinamik havuzu bastırır, OpenVPN 2.6 kılavuzunun açıkladığı gibi. Ardından açık ifconfig-pool satırı amaçladığınız kapsayıcı aralığı verir ve ağ maskesi alt ağla eşleşir. İki satır da aynı sunucu bloğuna aittir, çünkü alt ağı olmayan bir havuzun anlamı yoktur. Aralarındaki sıra yalnızca okunabilirlik için önemlidir, çünkü yardımcı hizmet başlarken çifti açar.

topology subnet
server 10.70.0.0 255.255.255.0 nopool
ifconfig-pool 10.70.0.50 10.70.0.120 255.255.255.0

İki sınır da kapsayıcıdır, bu yüzden örnek yetmiş bir adres sunar. Sunucu adresini ve her sabit atamayı bu aralığın dışında tutun; dinamik aralığın içine düşen sabit atama, bağlantı sırasına bağlı bir çakışma üretir ve bu, ayıklaması en kötü türdür. Sabit atamaların büyümesi muhtemelse ayrılmış küme ile aralık arasında pay bırakın.

Aralığın boyutu ve eşzamanlılık ayrı sınırlardır. max-clients başka bir şey söylüyorsa yüz adres yüz eşzamanlı istemci demek değildir ve eşzamanlılık sınırından büyük bir havuz israf değil normaldir. Önemli olan iki sınırın varsayılandan miras alınmak yerine bilinçli seçilmesidir.

Sabit atamaları dinamik aralığın dışında tutun

İstemciye özel ifconfig-push, havuzdan dağıtımdan farklı bir mekanizmadır ve etkin topolojiye uygun parametreler kullanmalıdır. Alt ağ kipinde bu tek bir adres ve ağ maskesidir; eski bir örnekte göründüğü için net30 çiftini taşımak yaygın bir hatadır.

Dağıtım geçmişi bir ipucudur, otorite değildir. persist dosyası hangi istemcinin hangi adrese sahip olduğunu hatırlar, bu yüzden yeniden bağlanan istemciler genellikle aynısını alır ve adres ayırmaz, serbest bırakmaz veya sabit bir atamanın yerini almaz. Belirli bir aygıt her zaman belirli bir adrese sahip olmalıysa, persist dosyasına güvenmek yerine sabit atama kullanın.

Ardından adreslere bağlı yolları denetleyin. İstemcilere itilen yol, bir alt ağı kabul eden güvenlik duvarı kuralı veya belirli bir ana makine bekleyen izleme denetimi eski aralığı varsayabilir. Havuzu bunları okumadan değiştirmek arızayı ilgisiz görünen bir yere taşır.

Yaşam döngüsü boyunca uygulayın, sonra doğrulayın

Değişikliği hizmetin yapılandırmayı genellikle aldığı biçimde uygulayın — ister doğrudan dosya ve yeniden başlatma, ister dosyayı yeniden üreten bir yönetim katmanı. Üretilen dosyada elle yapılan değişiklik bir sonraki üretime kadar dayanır, daha fazla değil. Dosyanın hangi mekanizmaya ait olduğunu kaydedin, çünkü sonraki operatörün aynı değişikliği nerede yapacağını bilmesi gerekir. Ardından bir kez yeniden başlatın ve istemciyi davet etmeden önce günlüğü okuyun.

systemctl restart openvpn-server@lab
journalctl -u openvpn-server@lab -n 30 --no-pager
# on a fresh client
ip -4 addr show tun0

Daha önce bağlanmamış bir istemci bağlayın ve adresin bildirilen aralığın içinde, ayrılmış kümenin dışında olduğunu doğrulayın. Ardından dönüş yolunu doğrulayın: istemci ilkenin izin verdiğine ulaşmalı, fazlasına değil. Plana uyan ama çalışan yolu olmayan adres başarılı bir değişiklik değildir.

Eski aralıktan adres tutan bir istemciyi yeniden bağlayın. Yeni aralıktan adres almalı ve eski adrese bağlı oturum düzeyi durum kalmamalı. Eski adresi koruyorsa onu başka bir şey atıyor demektir ve havuz sandığınız sahip değildir.

Aralık değişikliğini geri alma

Değişiklik kaydınızda önceki üç satırı saklayın, yalnızca önceki dosyayı değil. Bunları geri yükleyip yeniden başlatmak dağıtımı eski davranışa döndürür ve sonrasında yeniden bağlanan istemciler oradan adres alır.

Kayda iki uyarı girer. Geri alma sırasında zaten bağlı olan istemciler yeniden bağlanana kadar mevcut adreslerini korur, yani geri alma tüm filoda anında değildir. Ve eski aralık bir sabit atamayla çakışıyorsa, geri yüklemek çakışmayı da geri getirir; o çakışma değişikliğin nedenidir ve geri almadan farklı bir düzeltme gerektirir.

Havuz değişikliği, yeni bir istemci aralık içinde adres aldığında, ayrılmış adres hiçbir zaman verilmediğinde ve bu adresleri tüketen yollar ile kurallar amaçlandığı gibi davranmaya devam ettiğinde tamamlanır. Bundan azı, üçünden hangisinin doğru olmadığını bulmayı bir sonraki kişiye bırakır.