AWS Client VPN'de aralıklı erişim: ilişkili her alt ağı denetleyin

Bir kullanıcı bağlanır, iç uygulamayı açar ve yanıt alır; aynı uç noktadaki bir iş arkadaşı aynı Wi-Fi'daki aynı dizüstü bilgisayardan zaman aşımı alır. Bu desen, birden fazla ilişkili alt ağı olan bir client VPN uç noktasının imzasıdır ve burada yollar eşdeğer değildir. Bunu konsoldan dışarı doğru inceliyorum, çünkü iki sekme araştırmanın geri kalanının buna değip değmeyeceğine karar verir. İstemci yapılandırmasında bunu açıklayan hiçbir şey yok.

Uç noktadan başlayın ve ilişkilendirmeleri listeleyin

VPC konsolunda Client VPN endpoints'i açın, uç noktayı seçin ve Associations sekmesini okuyun. Her ilişkilendirme bir kullanılabilirlik bölgesindeki alt ağdır ve istemci bağlantı kurulurken hizmetin seçtiği alt ağa iner. Alt ağ kimliklerini ve her birinin gerçekte kullandığı rota tablosunu not edin, çünkü bu iki liste yapmak üzere olduğunuz karşılaştırmadır.

Uç nokta yalnızca tek bir ilişkilendirme gösteriyorsa bu teori yanlıştır ve istemci daha iyi bir şüphelidir.

Uç nokta rota tablosunu her ilişkilendirmeyle karşılaştırın

Aynı uç noktada Route table sekmesini açın. Oradaki her hedef CIDR'ın bir hedefi vardır ve bir client VPN'de hedef ağ geçidi değil ilişkilendirmedir. AWS her ilişkili alt ağ için bir hedef girdisi ister, bu yüzden yalnızca birine yönelen bir rota erişimi oturumun nereye indiğine bağlı kılar. Gerçekten önemsediğiniz hedefi, ardından yetkilendirme kuralını kontrol edin, çünkü rotayı yol sağlar, kuralı ise kimin kullanabileceğini belirler.

İki katmanı da tabloya döktüğünüzde arızayı gözden kaçırmak zorlaşır.

Çoğu talepte ikinci satır arızanın tamamıdır. Uç nokta rotası vardır, bu yüzden kimse ötesine bakmaz ve paket bir sıçrama sonra VPC'nin içinde ölür.

Her alt ağı geçerli rota tablosuna kadar izleyin

Açık bir rota tablosu ilişkilendirmesi olmayan bir alt ağ VPC'nin ana tablosunu devralır. Gerçekten yürürlükte olan tabloyu okuyun, adı doğru görüneni değil, ve satırdaki etiket yerine hedef ile hedef nesneyi karşılaştırın.

AWS'nin aralıklı erişim kılavuzu bunu ilişkilendirmeler arasında rota kapsamı olarak ele alır, ki doğru model budur. Uç nokta paketi bir alt ağa ulaştırır ve o alt ağın tablosu uygulama ağının nerede olduğunu hâlâ bilmelidir.

Eksik satırı ona sahip olan tabloda düzeltin. Çalışan bir alt ağdan tüm rota tablosunu kopyalamak, bu alt ağ için hiç düşünülmemiş internet, cihaz ve yalıtım seçimlerini de kopyalar ve bu takas genellikle başladığınız kesintiden daha kötüdür.

Yetkilendirme kurallarını, ardından dönüş yolunu kontrol edin

Yetkilendirme kuralları hedefe ve gruba göredir ve rotalardan ayrı değerlendirilir. Her yerde rotası olan ama kullanıcının grubu için kuralı olmayan bir hedef, sağlıklı görünen rota tablosuyla bir kara delik gibi davranır.

Dönüş yolu da aynı dikkati hak eder. Peering bağlantısı, uygulama VPC'sinde istemci CIDR'ına geri bakan bir rota, iki uçta trafiğe izin veren güvenlik grubu kuralları ve onu düşürmeyen ağ ACL'leri gerektirir. Tek yönlü erişilebilirlik, yani ping çalışıp TCP el sıkışması çalışmadığında, genellikle VPN'e değil bir ACL'ye veya güvenlik grubuna işaret eder.

Uç noktanın kendi güvenlik grupları ilişkilendirmenin elastik ağ arayüzlerinde oturur, bu yüzden uygulama bağlantı noktasına istemci CIDR'ından izin veren kural yalnızca örneğe değil, ilişkilendirmeye de eklenmelidir.

Tek bir şanslı istekle değil, yeniden bağlanarak doğrulayın

Split tunnel ile uç nokta rotaları bağlantı kurulduğunda gönderilir, böylece değişen rota kümesi bağlı kalan bir istemciye asla ulaşmaz. Desteklenen istemci üzerinden bağlantıyı kesip yeniden bağlanın, ardından yeni rotaların makinede olduğunu doğrulayın.

Son olarak, bağlantı günlüğünü istemcinin aldığı adresle ilişkilendirin ve birden fazla ilişkilendirmeye denk gelmek için testi yeterince tekrarlayın. Düzeltmeden sonra tek bir başarılı istek bir yolun çalıştığını kanıtlar ve talep diğeriyle ilgiliydi.