İki sunucuda tek bir VPN hesabı: üç durum defteri

İki VPN düğümünden herhangi birine giriş yapabilen tek bir hesap, yazılım sorusu olmadan çok önce bir tasarım sorusu ortaya çıkarır. Hesap görünümü, her düğümün sahip olduğu ağ ve bağlı bir istemcinin tuttuğu oturum üç farklı durum türüdür ve bunları oradan oraya kopyaladığınızda farklı biçimlerde bozulurlar. Üçünü de tek bir sisteme kopyalamak, içlerinden birini kaybetmenin yaygın bir yoludur.

Aşağıdaki üç defteri sırayla inceleyin. Her biri neyin yetkili, neyin yerel olduğunu ve diğer düğüm yokken ne olacağını sorar; yanıtlar birbirinden türemez.

Kim bağlanabilir: tek yetkili, çok düğüm

Kabul defteriyle başlayın: hangi kimlik kaynağının yetkili olduğu, hangi sertifika verenlere güvenildiği, hangi hesapların uygun olduğu, hangi ikinci faktörün geçerli olduğu ve her hesabın neye ulaşabildiği. Ardından her düğümün değişiklikleri nasıl öğrendiğini ve ne kadar hızlı öğrendiğini yazın.

Paylaşılan bir veritabanı bu yanıtın olası bir bileşenidir. İlgili her politikanın orada yaşadığının ya da her düğümün bir değişikliği aynı anda uyguladığının kanıtı değildir. A düğümünde devre dışı bırakılmış ama B düğümünde hâlâ kabul edilen bir hesap, ayrılma sürecinin bitmediği anlamına gelir.

Yetkiliye ulaşılamadığında düğümün ne yapacağına karar verin. Kesinti sırasında önbelleğe alınmış kimlik bilgilerini kabul etmek güvenlik maliyeti olan bir politika seçimidir; reddetmek ise kullanılabilirlik maliyeti olan bir politika seçimidir. İkisi de savunulabilir; belgelenmemiş bırakmak değil.

Verenin yetkisini hesap verilerinden ayrı tutun. Birçok geçit, imzalama anahtarını elinde tutmadan aynı CA’ya güvenebilir ve her düğüm yine de kendi sunucu sertifikasına ve kendi istemci tarafı güven ilişkisine ihtiyaç duyar.

Bir düğüm neye sahiptir: adresler ve rotalar

İkinci defter her düğüm için yereldir: dinleme adresi, sunucu kimliği, adres havuzu, özel kaynaklara rotalar, çözümleyici politikası ve trafiğin internete nasıl çıktığı. Aynı hesap iki düğümden herhangi biri tarafından sunulabilirken bu nesneler ayrı kalır.

Dönüş yolu unutulan kısımdır. İki düğüm de aynı havuzdan adres dağıtırsa, özel ağ belirli bir istemcinin hangi düğüme ait olduğunu söyleyemez ve yanıt yanlış yere gidebilir. Farklı havuzlar da rota ve izin gerektirir, bu yüzden ayrı bir sayı aralığı tam bir tasarım değildir.

İstemcileri bilinçli olarak bir düğüme yönlendirin. DNS seçimi, istemci uç nokta listeleri ve bir ön uç hizmeti farklı sağlık ve yük devretme davranışına sahip farklı mekanizmalardır. Birini seçmek sorun değildir; «yük dengelemeyi» tasarımın kendisi saymak dönüş yolunu ve hata davranışını tanımsız bırakır.

Belgelenmiş bir ürün örneği burada yardımcı olur. Pritunl’ın çoğaltma belgeleri VPN ağını her kopya için bir nesne olarak ele alır ve farklı kopyalardaki istemcilerin birbirine ulaşması için ek rotalar ve bağlantı gerekir. Bu, ürüne özgü bir düzenlemedir, Community OpenVPN için bir tarif değildir, ancak bir kopya eklemenin yalnızca hesap deposunu değil ağı da değiştirdiğini gösterir.

Oturum nedir: satır değil, canlı durum

Üçüncü defter canlı oturumdur. Bağlı bir istemcinin onu kabul eden düğümde protokol durumu ve ağ ataması vardır. Hesabın diğer düğümde bilinmesi o düğüme oturumu, anahtarları veya paketleri sürdürme yeteneğini vermez.

Bir düğüm arızalandığında ne olacağı konusunda açık olun. Desteklenen sonuç, yeni kimlik doğrulama ve yeni adresle diğer düğüme yeniden bağlanmak olabilir; ardından uygulama kendi biçiminde toparlanır. Kesintisiz devir gerekiyorsa, bu gereksinim açık uygulama desteği gerektirir; veritabanı çoğaltmasından çıkarılan bir sonuç değil. Yanıtı nöbetçi mühendisin bulabileceği yere yazın.

Kapasite kuralları da aynı muameleyi gerektirir. Hesap başına iki eşzamanlı oturum sınırı, ancak bir yetkilinin dolu yerler hakkında eşgüdümlü bir görünümü varsa düğümler arasında uygulanabilir. Düğüme yerel listeler ve geçmiş bir hesap kaydı bu görünümü oluşturmaz.

Üç defteri denemek

Her birini ayrı ayrı çalışın. A düğümünden, ardından B düğümünden oturum açın ve ikisinin de beklenen adres aralıklarıyla başarılı olduğunu doğrulayın. Bir kimliği geri çekin ve yalnızca rastlantısal olarak test ettiğiniz düğümü değil, iki düğümü de denetleyin. Sonra bir düğümü durdurun ve istemcinin ve özel uygulamanın gerçekte ne yaptığını gözlemleyin.

Kabul testine dönüş yolunu da katın. B’ye bağlanan ancak A’nın arkasındaki bir kaynaktan yanıt alamayan bir istemci, kabul denetimini geçmiş ve ağ denetiminde başarısız olmuştur; bu ayrım raporda yer almalıdır.

Çok düğümlü hesap tasarımı, ancak üç defterin de açık bir sahibi, bir değişiklik yolu ve bir hata davranışı olduğunda tamamlanır. Yapılandırma dosyasını düğümler arasında kopyalamak bu soruların hiçbirini yanıtlamaz.