Odamlar AWS Site-to-Site VPN paketni qayerda himoya qilishni to'xtatishini so'rab, bitta javob kutishadi: shlyuzda. Bu javobning foydali varianti qaysi shlyuz ekanini nomlaydi, chunki virtual xususiy shlyuz va tranzit shlyuzi turli biriktirma obyektlari bo'lgan turli tuzilmalar, va noto'g'risini taxmin qilgan taqrizchi baholashning qolgan qismini mavjud bo'lmagan diagramma ustiga quradi. Quyidagi uchta tekshiruvni tartib bilan bajaring. Har biri yo chegarani tasdiqlaydi, yo oldingi javob boshqa resurs haqida bo'lganini aytadi.

Biror narsani baholashdan oldin uchta oxirgi nuqtani nomlang

Bu yo'lning shifrlash taqrizi uchta nomlangan narsani talab qiladi: mijoz shlyuzi, IPsecni tugatuvchi AWS VPN maqsadi va ichki paketni qabul qiluvchi ilova oxirgi nuqtasi. Bitta konsol sahifasini ochishdan oldin ularni resurs identifikatorlari bilan yozib qo'ying, chunki bu nuqtadan keyingi hamma narsa o'sha uchtadan biri haqidagi bayonot.

Mijoz shlyuzi sizniki va uning konfiguratsiyasi sizga ko'rinadi. AWS maqsadi boshqariladigan resurs, va xato uni taxmin qilishdir: VPN ulanishi virtual xususiy shlyuzga yoki to'g'ridan-to'g'ri tranzit shlyuziga biriktirilishi mumkin, va hech biri ikkinchisini anglatmaydi. Uchinchi oxirgi nuqta odamlar tashlab ketadigan nuqta, va ilova ma'lumotlari haqidagi haqiqiy savolga faqat shu javob beradi.

Tekshiruv 1: tunnelni aslida qaysi shlyuz tugatadi

Ikkala tuzilma ham qo'llab-quvvatlanadi va Site-to-Site VPN arxitektura qo'llanmasi ularni yonma-yon tasvirlaydi, shuning uchun ko'pincha bir yillik diagramma o'rniga APIdan so'rang. Bitta ulanish bo'yicha faqat o'qish so'rovi VPN maqsad maydonlarini qaytaradi:

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}'

Farqlovchi — TransitGatewayId, VpnGatewayId emas. TransitGatewayId bo'sh bo'lgan ulanish alohida virtual xususiy shlyuzda tugaydi, bu maydon o'rnatilgan ulanish esa tranzit shlyuzining VPN biriktirmasida tugaydi, va bu holatda VpnGatewayId hali ham to'ldirilgan bo'lishi mumkin, chunki u biriktirmaning tayanch shlyuzini nomlashi mumkin. Avval TGW maydonini o'qing, so'ng biriktirma turini maydon nomidan emas, biriktirmalar ro'yxatidan tasdiqlang, chunki o'sha tranzit shlyuzidagi VPC biriktirmasi VPN biriktirmasi emas. Ulangan VPCda maqsad instansni topish paketni qaysi VPN biriktirmasi olib o'tgani haqida hech narsa demaydi.

U yerda bo'lganingizda tunnellarni ham tekshiring. Ulanish ortiqchalik uchun ikkita IPsec tunnelini olib yuradi, va ikkinchi tunneli hech qachon ko'tarilmagan ulanish shifrlash chegarasida hech narsani o'zgartirmasa ham mavjudlik uchun haqiqiy topilma:

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}'

Tekshiruv 2: ichki paket hali nima olib yuradi

IPsec tugagach, AWS kapsuladan chiqarilgan paketni unga mos kelgan marshrut bo'ylab uzatadi. Shu nuqtadan trafik oddiy VPC trafigi, va VPN himoyasi tugagan. Bu xizmatdagi bo'shliq emas; bu chegaraning ma'nosi, va ro'yxatdagi band — buni ochiq aytish, "VPN shifrlangan" iborasini "ma'lumotlar uchdan-uchga shifrlangan" o'rniga qo'yishga yo'l qo'ymaslik.

Endi ichida nima bo'lganini ko'rib chiqing. Agar ichki paket ochiq matnli ilova protokoli bo'lsa, boshqa narsa uni shifrlamaguncha pastda hech narsa maxfiylik qo'shmaydi. Agar ichki paket allaqachon TLS sessiyasini olib yursa, tashqi IPsecni olib tashlash o'sha sessiya uchun hech narsani o'zgartirmaydi: u o'zining oxirgi nuqtasigacha himoyalangan qoladi, o'sha nuqta qayerda bo'lishidan qat'i nazar.

Odatiy haddan tashqari tuzatish — shlyuz orqasidagi hamma narsa ochiq deb xulosa qilish. Unday emas. Xizmat transporti, saqlash shifrlashi va ilova TLsi alohida shartlarga ega alohida mexanizmlar, va har birini VPN shaklidan xulosa qilish o'rniga o'z shartlari bilan baholash kerak. ACCEPT ko'rsatadigan oqim jurnali yozuvi marshrutlash ishlaganini isbotlaydi va maxfiylik haqida hech narsa demaydi, va bu ro'yxat aynan shu xatoning oldini olish uchun mavjud.

Tekshiruv 3: shlyuz orqasida TLSni nima tugatadi

Manzilga emas, tinglovchiga ergashing. Agar yuk balanslagichi yoki proksi TLSni tugatsa, sizning mijozingiz ushlab turgan ulanish shu yerda tugaydi, va proksi backendga ikkinchi ulanish ochadi, u ochiq matn yoki boshqa ishonch zanjiriga ega TLS bo'lishi mumkin. Xususiy IP manzil va mos marshrut o'sha ikkinchi ulanish haqida dalil emas.

Sizga haqiqatan muhim bo'lgan oxirgi nuqtani VPC ichidan sinab ko'ring, bir marta hal qilgan IP bilan emas, ilova ishlatadigan nom bilan:

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

So'rov o'tadigan har bir sakrash uchun buni takrorlang. Agar javob mijozga qaragan nom va backend nomi o'rtasida farq qilsa, siz VPN hech qachon qamramagan o'sha segmentni topdingiz, va bu yozib qo'yilishi kerak bo'lgan topilma.

Natijani hukm sifatida emas, segmentlar sifatida yozing

Bu ro'yxatning chiqishi har bir segmentga bitta satr bo'lgan kichik jadval: mijoz shlyuzidan AWS VPN maqsadigacha, shlyuzdan ish yukigacha, ish yukidan ma'lumot omborigacha va oradagi har qanday proksi sakrashi. Har bir satr uni nima himoya qilishini va bu himoya nimaga bog'liqligini aytadi. Mexanizmsiz va oxirgi nuqtasiz "shifrlangan" satr emas.

So'ng asl talabga u qanday qo'yilgan bo'lsa, o'sha atamalar bilan javob bering. Agar talab ma'lumot ish yuki qabul qilgunga qadar maxfiy qolishi bo'lsa, VPN faqat birinchi segmentni qanoatlantiradi, qolgan satrlarga esa ilova transporti, xizmat TLsi yoki saqlash shifrlashi alohida sozlanib, tekshirilishi kerak.

Ulanish identifikatorlarini, tunnel holatlarini va sertifikat subyektlarini yozuvda saqlang. Kimdir olti oydan keyin dizaynga qaytsa, o'sha uchta artefakt chegara savoliga bir necha daqiqada javob beradi, diagrammadan bahsni qaytadan boshlash o'rniga.

O'xshash maqolalar