AWS Client VPN bölünmüş tünel: hangi rotaları yayınlamalısınız

Konsol bölünmüş tünel için bir anahtar sunuyor, bu yüzden karar onay kutusu gibi geliyor. Değil. İstemciye gerçekte ulaşan şey, uç noktanın yayınlanmış rota kümesidir ve bu liste hangi özel öneklerin tüneli kullandığını, genel internet trafiğinin yerel kalıp kalmadığını veya AWS üzerinden çıkıp çıkmadığını ve istemcinin hâlâ hangi çözümleyiciyle konuşabildiğini belirler. Üç soru tasarımı belirler ve her birine, bağlantı yine de başarılı olurken kötü yanıt verilebilir.

Bölünmüş tünel bayrağı bir hedef listesi değildir

AWS bölünmüş tüneli, bağlantı kurulurken uç nokta rotalarının istemcinin rota tablosuna eklenmesi olarak açıklar. Özel VPC için bir rota, tüneli o hedefle sınırlar; geri kalan her şey istemcinin olağan yolunu izler. Varsayılan rota, farklı etkiye sahip farklı bir yönergedir, bu yüzden bölünmüş tünel belgeleri bu mod için yapılandırılmış bir uç noktada 0.0.0.0/0 yayınlanmasına karşı uyarır: bu genellikle bağlantıyı genişletmek yerine kırar. Uç noktanın rota tablosu politikadır ve istemcinin rota tablosu inceleyebileceğiniz sonuçtur.

Uç noktanın rota tablosunu ve istemcinin yüklü rotalarını birlikte okuyun. Etiket bir niyeti anlatır; rotalar ne olduğunu anlatır.

Birinci karar: genel internet trafiği yerel kalmalı mı?

Tarama kullanıcının kendi bağlantısını kullanacaksa, yalnızca işin ihtiyaç duyduğu özel hedefleri yayınlayın ve orada durun. Tam tünel eğitimi bir tane içerdi diye internet rotası eklemeyin ve ek rotanın güvenliği iyileştirdiğini varsaymayın. Yolu değiştirir, politika eklemez ve genellikle bütçelemediğiniz bir gecikmeye mal olur.

İnternet trafiği AWS üzerinden çıkacaksa, belgelenmiş internet erişimi mimarisini kurun: uç nokta rotası, yetkilendirme kuralları, ilişkili alt ağın yolu, güvenlik politikası ve çalışan bir üst çıkış. Tek başına varsayılan rota bunların hiçbirini sağlamaz.

İkinci karar: hangi özel önekler ve kimin yetkilendirmesiyle?

Gerçek iş yüküne hizmet eden en küçük hedef kümesini yayınlayın ve ilişkili her alt ağın oraya yönlendirme yapabildiğini doğrulayın. Uç noktanın rota hedefi ile alt ağın VPC yönlendirmesi farklı katmanlardır ve birinde var olan rota diğeri hakkında kanıt değildir. Yetkilendirme yine ayrıdır: bir hedef erişilebilir olsa bile, istemcinin grubunun izin veren bir kuralı olmadığı için reddedilebilir.

Tek bir başarılı oturumu test etmek tek bir yolu kanıtlar. İlişkili her alt ağı denetleyin, çünkü sonradan eklenen alt ağ ilişkilendirmesi eksik rotanın genellikle bulunduğu tam yerdir.

Bir hedef ada göre erişilebilir olması gerektiğinde, sıradaki sorunun rota değil ad çözümlemesi olduğunu unutmayın.

Üçüncü karar: hangi çözümleyici tüneli izler?

İstemci yalnızca VPN üzerinden erişilebilen bir DNS sunucusu alabilir ve bu çözümleyici yalnızca adresi yetkili bir rotanın içindeyse çalışır. İki yarıyı da doğrulayın: çözümleyici adresi yayınlanmış bir rotayı izler ve sunucu uygulamanın sorduğu adları yanıtlar. Adresle başarılı olup ana makine adıyla başarısız olan bir istek adlandırmaya işaret eder, yönlendirmeye değil, ve o durumda tünelde hata ayıklamak öğleden sonrayı boşa harcar.

Genel adlar bağlantıdan önceki gibi çözümlenmelidir, bu da neyi yayınladığınız konusunda kesin olmanız için başka bir nedendir.

Rota kümesini değiştirin, sonra iki dünyayı da doğrulayın

AWS, bölünmüş tünel uç noktasında rotaların değiştirilmesinin istemci bağlantılarını sıfırladığını belgeler. Değişikliği bunu göz önünde tutarak planlayın: uygulayın, desteklenen istemciyle yeniden bağlanın ve düzenlemeden önce uygulanan duruma güvenmek yerine yüklü rotaları yeniden okuyun. Eskimiş uygulanmış durum, doğru bir değişikliğin bozuk görünmesinin en yaygın nedenidir.

Tasarımı yalnızca bir özel kaynak ve bir genel hedef, hem adla hem adresle, gerçekten desteklediğiniz adres ailelerinde amaçlandığı gibi davrandığında kabul edin. Kimlik doğrulayan tünel, doğru bölen tünelle aynı şey değildir.

Rota listesini gerekçenin yanına runbook'a yazın, böylece sonraki kişi kasıtlı bir dışlamayı unutulmuş olandan ayırabilsin.