EC2 neden AWS Client VPN dizüstü bilgisayarınıza ulaşamıyor
Client VPN, IPv4 istemci kaynaklarını uç noktanın ağ arayüzüne çevirir. Bu yüzden yanıt çalışır, EC2'den gelen yeni bağlantı çalışmaz.
AWS Client VPN üzerinden bağlanan bir dizüstü bilgisayar, EC2 üzerindeki bir uygulamaya sorunsuz ulaşır. Sonra tersini denersiniz, EC2'den istemciye atanan adrese, ve bağlantı askıda kalır ya da reddedilir. Bu asimetri nadiren eksik bir güvenlik grubu kuralıdır. VPC alt ağlarıyla ilişkilendirilmiş bir Client VPN uç noktasında AWS, IPv4 istemci kaynaklarını uç noktanın ağ arayüzüne çevirir, bu yüzden dizüstü bilgisayarınızı temsil eden gelen bir VPC adresi yoktur.
Yakalamanın gösterdiğiyle başlayın
İstemci bağlanırken EC2 ana bilgisayarında yakalama yapın ve uygulamanın gerçekte gördüğü kaynak adresini okuyun. Eğer bu, istemci havuzundan bir adres değil de VPC tarafındaki uç nokta arayüzü ise, tek bir kuralı değiştirmeden önce çeviri doğrulanmıştır.
İstemci havuzu bir tahsis aralığıdır, dönüş yolu olan bir alt ağ değildir. Bu ayrımda bu tür incelemelerin çoğu yanlış gider.
Asimetriyi açıklayan çeviri
Üç akış birbiriyle karıştırılır ve bunlardan yalnızca biri insanların test ettiği akıştır.
| Flow | Started by | What the VPC sees | Outcome |
|---|---|---|---|
| Client to EC2 service | The client | A translated source at the endpoint interface | Works, with a stateful reply |
| EC2 host to client pool address | The EC2 host | A destination with no route and no translation state | No usable path |
| Client to client | A client, when the feature is configured | Traffic mediated by the endpoint | Works only with that feature and its authorisation |
Client VPN bileşenlerinin açıklaması, IPv4 istemci kaynaklarının uç nokta arayüzüne çevrildiğini açıkça belirtir; bu da orta satırın neden eşleştirecek bir şeyi olmadığını görmek için yeterlidir.
Yeni bir bağlantı bir yol, bir adres çözümleme adımı ve bir yetkilendirme kararı gerektirir. Başka birinin oturumundaki çeviri durumu bunların hiçbirini sağlamaz.
Yanıt neden yeni bir bağlantı değil
TCP yanıtı mevcut bir kayıtla eşleştirilir, bu yüzden dönüş yolu hiçbir gelen kural olmadan çalışır. EC2 ana bilgisayarından gelen yeni SYN'in eşleştirecek kaydı yoktur, bu yüzden VPC'nin nasıl ulaşacağını bilmediği bir hedefe yönelik sıradan bir giden denemeye dönüşür.
Bu yüzden bunu yalnızca tek yöne giden trafik olarak tanımlamak yanıltıcıdır. Bu oturumlarda dönüş trafiği sürekli akar. Yolu olmayan kısım başlatmadır.
Çalışması gereken bir oturumu hâlâ ne bozuyor
Güvenlik grupları, ağ ACL'leri ve dizüstü bilgisayarın kendi güvenlik duvarı, başarılı olması gereken bağlantılar için önemlidir. Başarısız bir ping en azını söyler, çünkü ICMP politikası çoğu zaman ilgilendiğiniz TCP politikasından ayrıdır.
Bu kuralları çevrilen kaynağa göre yazın, istemci adresine göre değil. Ağda hiç görünmeyen adrese bağlanmış kurallar bu tasarımdaki en yaygın kendi kendine yol açılan hatadır.
VPC gerçekten konuşmayı başlatmak zorunda kaldığında
Bir hizmet bir iş istasyonuna bildirim yapmak zorundaysa yönü tersine çevirin ve istemcinin hizmetin yanıt verdiği kalıcı bir giden kanal tutmasına izin verin. Tüm uzak ağın VPC'den erişilebilir olması gerekiyorsa, Client VPN'in bunu zaten yaptığını varsaymak yerine öneklerini ve erişim politikasını yayımlayan bir mimari seçin. İstemciden istemciye erişim, kendi yol ve yetkilendirme nesnelerine sahip üçüncü ve daha dar bir durumdur. Bunların hiçbiri mevcut uç noktada yalnızca bir onay kutusu değildir.
IPv4 açıklamasının kapsamını da dürüst tutun. Güncel AWS belgeleri, bu çevirinin uygulanmadığı IPv6'yı ve farklı yönlendirme yapan diğer bağlantı modellerini ayırır.
Üç etiketli adımda test edin: istemci izin verilen bir oturum açar, VPC'deki hizmet o oturuma yanıt verir ve bir VPC ana bilgisayarı istemciye doğru yeni bir oturum açar. İlk ikisinin başarılı olup üçüncüsünün başarısız olması bu tasarımın beklenen biçimidir, güvenlik duvarı kurallarıyla peşine düşülecek bir kusur değildir.