Bir EC2 Elastic IP, örneğin özel VPN adresi değildir

Örneğin özel bir adresi vardır, Elastic IP ona ilişkilendirilmiştir ve o genel /32 için bir yol, ikisinin aynı şey olacağı umuduyla VPN'e eklenir. Olmazlar. Elastic IP, konuğun dışında, internet ağ geçidi tarafından, internet yolunu izleyen trafik üzerinde yapılan bir çeviridir. Konuğun işletim sistemi o adresi hiçbir zaman bir arayüzde yapılandırılmış olarak görmez. Onu bir tünel arayüzüne eklemek yukarı akıştaki çeviriyi yeniden üretmez ve aynı makine için ikinci, çelişkili bir kimlik yaratır.

İki adres, bir örnek

Örneğin ağ arayüzü VPC içinde özel bir adres tutar ve bu, konuğun bildiği adrestir. Elastic IP aynı arayüze ilişkilendirilmiştir ancak eşlemenin genel tarafında yaşar.

Örneğe internet üzerinden ulaşan her şey özel adrese çevrilmiş olarak gelir. Örneğin internete gönderdiği her şey kaynak olarak Elastic IP ile çıkar, yine o çeviri nedeniyle.

Konuğun içinde tek bir adres vardır. Dışında iki tane vardır. Bu asimetri bu alandaki karışıklığın çoğunu açıklar. Konuk ağ geçidinin neyi çevirdiğini yapılandıramaz. Yalnızca gerçekten sahip olduğu adreste yanıt verebilir.

İnternet ağ geçidi gerçekte ne yapar

AWS'nin internet ağ geçidi belgeleri düzeni açıklar: örnek özel IPv4 adresinin farkındadır ve ağ geçidi internet yolundaki trafik için karşılık gelen genel IPv4 veya Elastic IP çevirisini sağlar.

Bu, ağ adresi çevirisidir, takma ad değildir. Eşlemeyi ağ geçidi sürdürür, ilişkilendirmeye bağlıdır ve yalnızca ondan geçen paketler için geçerlidir. İlişkilendirmeyi kaldırın, genel kimlik konuk hiçbir şey fark etmeden kaybolur.

Bu yüzden genel /32'ye adreslenen özel bir VPN paketi, konuğun yerel adresine giden özel bir paket olarak yeniden yorumlanmaz. Paket, eşleştiği yolu izler, bu da onu internet ağ geçidine gönderir ve ağ geçidinin davranışı yolun her iki yönde de izinli olup olmamasına bağlıdır.

Tünel arayüzü numarası neden başarısız olur

Elastic IP'yi bir tünel arayüzüne atamak, konuktan genel bir adresi yerel olarak görmesini ister. Şimdi iki şey aynı adresi talep eder: internet yolundaki ağ geçidi çevirisi ve tünelin içindeki yerel arayüz. Dönüş trafiğinin hangisinin geçerli olduğuna dair tutarlı bir yanıtı yoktur.

Çalışıyor gibi görünse bile, tasarım gerçek soruyu gizlemiştir. İstemciler ya tünel üzerinden özel adrese ya da internet üzerinden genel uç noktaya ulaşır ve iki yolun güvenlik grupları, günlük kaydı ve arıza biçimleri farklıdır.

Adres hiçbir zaman sorun değildi. Yol seçimiydi.

Üç amaç, üç tasarım

Amaç genel bir VPN uç noktasıysa, Elastic IP doğru araçtır: uzak eşler internet üzerinden ona bağlanır ve şifrelenmiş taşıma örnek üzerinde sonlanır. İç uygulama trafiği sonra özel adresi kullanır.

Amaç uygulamaya özel erişimse, hedef özel adres veya ona çözülen özel bir DNS adıdır ve VPN yolu, güvenlik grubu ve dönüş yolu hepsi uyuşmalıdır. Elastic IP o tasarımda hiç görünmez.

Amaç VPN kullanıcıları için kararlı bir genel çıkış kimliğiyse, bu çıkış tarafında bir NAT tasarımıdır, istemcinin tünelindeki bir adres değildir. Benzer görünen üç amaç üç farklı diyagram üretir ve yalnızca biri Elastic IP'yi yeni bir yere koymayı içerir.

Seçtiğiniz yolu doğrulayın

Özel erişim için VPN yolunun özel öneki kapsadığını, VPC yol tablosunun trafiği tünele geri gönderdiğini, güvenlik grubunun istemci kaynağına izin verdiğini ve istemcinin kendi güvenlik duvarının yanıta izin verdiğini doğrulayın. Sonra ping yerine gerçek bir isteği test edin.

Genel erişim için istemcinin internet çıkışını, genel girişin yönlendirmesini ve güvenlik politikasını doğrulayın. Bir VPN istemcisinin tünel üzerinden genel bir uç noktaya ulaşıp ulaşamaması tünelin çıkış ve güvenlik duvarı kurallarına bağlıdır, Elastic IP ilişkilendirmesine değil.

Genel bir ana bilgisayar adının iki taraftan da çalışması gerekiyorsa, VPN istemcileri için özel adresle ve diğer herkes için genel adresle yanıt veren bir DNS tasarımı kullanın ve sertifikayı adres yerine ad için geçerli tutun. İş sırası: amacı adlandırın, ona ait adresi seçin, sonra yolları, politikayı ve bir isteği doğrulayın.