VGW mi TGW mi? AWS Site-to-Site IPsec tüneli nerede biter

İnsanlar bir AWS Site-to-Site VPN'in paketi korumayı nerede bıraktığını sorar ve tek bir yanıt bekler: ağ geçidinde. Bu yanıtın işe yarar sürümü hangi ağ geçidi olduğunu adlandırır, çünkü sanal özel ağ geçidi ile geçiş ağ geçidi farklı bağlantı nesnelerine sahip farklı düzenlerdir ve yanlış olanı varsayan gözden geçiren, değerlendirmenin geri kalanını var olmayan bir diyagram üzerine kurar. Aşağıdaki üç kontrolü sırayla yapın. Her biri ya sınırı doğrular ya da önceki yanıtın başka bir kaynakla ilgili olduğunu söyler.

Herhangi bir şeyi değerlendirmeden önce üç uç noktayı adlandırın

Bu yolun şifreleme incelemesi üç adlandırılmış şeye ihtiyaç duyar: müşteri ağ geçidi, IPsec'i sonlandıran AWS VPN hedefi ve iç paketi alan uygulama uç noktası. Tek bir konsol sayfası açmadan önce bunları kaynak tanımlayıcılarıyla yazın, çünkü bu noktadan sonra her şey o üçünden biri hakkında bir ifadedir.

Müşteri ağ geçidi sizindir ve yapılandırması sizin için görünürdür. AWS hedefi yönetilen bir kaynaktır ve hata onu varsaymaktır: bir VPN bağlantısı sanal özel ağ geçidine veya doğrudan geçiş ağ geçidine bağlanabilir ve hiçbiri diğerini gerektirmez. Üçüncü uç nokta insanların atladığı noktadır ve uygulama verileriyle ilgili gerçek soruya yanıt veren tek nokta odur.

Kontrol 1: tüneli gerçekte hangi ağ geçidi bitirir

Her iki düzen de desteklenir ve Site-to-Site VPN mimari kılavuzu ikisini yan yana açıklar, bu yüzden genellikle bir yıllık olan diyagram yerine API'ye sorun. Tek bir bağlantı üzerinde salt okunur bir sorgu VPN hedef alanlarını döndürür:

aws ec2 describe-vpn-connections --region eu-west-1   --vpn-connection-ids vpn-0123456789abcdef0   --query 'VpnConnections[0].{VGW:VpnGatewayId,TGW:TransitGatewayId,CGW:CustomerGatewayId,Category:Category}'

Ayırt edici TransitGatewayId, VpnGatewayId değil. TransitGatewayId boş olan bağlantı bağımsız bir sanal özel ağ geçidinde biter, o alan ayarlı olan bağlantı ise bir geçiş ağ geçidi VPN bağlantısında biter ve o durumda VpnGatewayId hâlâ dolu olabilir çünkü bağlantının taşıyıcı ağ geçidini adlandırabilir. Önce TGW alanını okuyun, sonra bağlantı türünü alan adından değil bağlantı listesinden doğrulayın, çünkü o geçiş ağ geçidindeki VPC bağlantısı VPN bağlantısı değildir. Hedef örneği bağlı bir VPC'de bulmak, paketi hangi VPN bağlantısının taşıdığı hakkında hiçbir şey söylemez.

Oradayken tünelleri de kontrol edin. Bağlantı yedeklilik için iki IPsec tüneli taşır ve ikinci tüneli hiç açılmamış bir bağlantı, şifreleme sınırında hiçbir şeyi değiştirmese de kullanılabilirlik için gerçek bir bulgudur:

aws ec2 describe-vpn-tunnels --region eu-west-1   --filters Name=vpn-connection-id,Values=vpn-0123456789abcdef0   --query 'VpnTunnels[].{Outside:OutsideIpAddress,State:State,Status:Status}'

Kontrol 2: iç paket hâlâ ne taşıyor

IPsec bittiğinde AWS, kapsülü açılmış paketi ona uyan rotadan iletir. O noktadan itibaren trafik olağan VPC trafiğidir ve VPN'in koruması sona ermiştir. Bu hizmette bir boşluk değildir; sınırın anlamı budur ve kontrol listesindeki madde bunu açıkça söylemektir, "VPN şifreli" ifadesinin "veriler uçtan uca şifreli" yerine geçmesine izin vermemektir.

Şimdi içeride ne olduğunu inceleyin. İç paket düz metin bir uygulama protokolüyse, başka bir şey onu şifreleyene kadar aşağı akışta hiçbir şey gizlilik eklemez. İç paket zaten bir TLS oturumu taşıyorsa, dış IPsec'in kaldırılması o oturum için hiçbir şeyi değiştirmez: oturum kendi uç noktasına kadar korunur, o uç nokta nerede olursa olsun.

Yaygın aşırı düzeltme, ağ geçidinin arkasındaki her şeyin açıkta olduğu sonucuna varmaktır. Değildir. Hizmet taşıması, depolama şifrelemesi ve uygulama TLS'i ayrı koşullara sahip ayrı mekanizmalardır ve her biri VPN'in biçiminden çıkarılmak yerine kendi koşullarıyla değerlendirilmelidir. ACCEPT gösteren bir akış günlüğü kaydı yönlendirmenin çalıştığını kanıtlar ve gizlilik hakkında hiçbir şey söylemez; bu kontrol listesinin önlemek için var olduğu hata tam olarak budur.

Kontrol 3: ağ geçidinin arkasında TLS'i ne bitirir

Adresi değil, dinleyiciyi izleyin. Bir yük dengeleyici veya vekil TLS'i bitirirse, istemcinizin tuttuğu bağlantı orada biter ve vekil arka uca ikinci bir bağlantı açar; bu bağlantı düz metin veya farklı bir güven zincirine sahip TLS olabilir. Özel bir IP adresi ve eşleşen bir rota, o ikinci bağlantı hakkında kanıt değildir.

Gerçekten önemsediğiniz uç noktayı VPC'nin içinden, bir kez çözdüğünüz IP ile değil uygulamanın kullandığı adla test edin:

openssl s_client -connect internal.example:443 -servername internal.example -verify_return_error

İsteğin geçtiği her atlama için bunu yineleyin. Yanıt, istemciye bakan ad ile arka uç adı arasında farklıysa, VPN'in hiçbir zaman kapsamadığı segmenti tam olarak buldunuz ve kaydedilmesi gereken bulgu odur.

Sonucu bir hüküm olarak değil, segmentler olarak kaydedin

Bu kontrol listesinin çıktısı, her segment için bir satır içeren küçük bir tablodur: müşteri ağ geçidinden AWS VPN hedefine, ağ geçidinden iş yüküne, iş yükünden veri deposuna ve aradaki her vekil atlaması. Her satır neyin onu koruduğunu ve bu korumanın neye bağlı olduğunu söyler. Mekanizmasız ve uç noktasız "şifreli" bir satır değildir.

Ardından özgün gereksinime, sorulduğu terimlerle yanıt verin. Gereksinim, verilerin iş yükü onları alana kadar gizli kalmasıysa, VPN yalnızca ilk segmenti karşılar ve kalan satırlar uygulama taşıması, hizmet TLS'i veya depolama şifrelemesinin ayrı olarak yapılandırılıp doğrulanmasını gerektirir.

Bağlantı tanımlayıcılarını, tünel durumlarını ve sertifika konularını kayıtta tutun. Biri altı ay sonra tasarıma geri döndüğünde, bu üç artefakt sınır sorusunu bir diyagramdan tartışmayı yeniden başlatmak yerine dakikalar içinde yanıtlar.