AWS Site-to-Site VPN-ээс NAT Gateway хүртэл: VGW эсвэл Transit Gateway

virtual private gateway нь Site-to-Site VPN-ийн урсгалыг NAT gateway-д дамжуулж чадахгүй. VGW ба transit gateway-ийн замыг, тус бүрд шаардлагатай route-уудыг харьцуулна уу.

Хүн бүр анх удаа ижил диаграм зурдаг: VPC руу VPN, дараа нь NAT gateway-аар интернет рүү, дууслаа. Гэвч VPN virtual private gateway дээр дуусах үед AWS энэ замыг дэмждэггүй бөгөөд алдаа нь маш нам гүм тул багууд үүнийг нэгээс олон удаа дахин барьдаг. Ажилладаг загварт transit gateway хэрэгтэй бөгөөд энэ нь хоёр талын gateway болон route хүснэгтийг өөрчилдөг. Ямар нэгэн юм зурахаас өмнө хоёр хэлбэрийг харьцуулна уу.

Илт мэт харагдах боловч дэмжигдэхгүй топологи

AWS-ийн NAT gateway-ийн баримт бичиг зөвхөн нэг VPC-ийн загвар барьсан хүн бүрийг гайхшруулдаг шугам татдаг: Site-to-Site VPN холболтын урсгалыг virtual private gateway-аар дамжуулан NAT gateway руу чиглүүлэх боломжгүй. VPN аль төрлийн gateway дээр дуусах нь орчуулгын зам байгаа эсэхийг шийддэг. Алдаа хэвээр байх шалтгаан нь туннелийн төлөв UP, мөн ижил subnet дахь EC2 инстанс интернетэд асуудалгүй хүрдэг. Эдгээр хоёр ажиглалтын аль нь ч эвдэрсэн чиглэлийг шалгахгүй.

Практикт пакет локал сүлжээний эх хаягтай ирээд түүнийг орчуулах дэмжигдсэн дараагийн hop олдохгүй. Хүснэгтээс хамаарч гарцын хязгаарт хаягдана, туннель UP хэвээр байх ба ижил subnet дахь инстанс интернетэд хүрдэг тул алдааг локал firewall-ийн асуудал гэж мэдээлдэг.

Virtual private gateway эсрэг transit gateway

Virtual private gateway нэг VPC-д хамаарна. Тэр VPN-ийг дуусгаж, тухайн VPC-ийн route хүснэгтэд route суулгаад тэнд зогсдог. Түүнд attachment загвар байхгүй тул урсгалыг өөр VPC эсвэл хуваалцсан гарцын сегмент рүү дамжуулж чадахгүй. Энэ нэг VPC-ийн хүрээ нь бүх хязгаарлалт бөгөөд VPC дотор нэмсэн ямар ч route үүнийг өөрчлөхгүй.

Transit gateway нь бүс нутгийн төв бөгөөд VPN, spoke VPC бүр, хуваалцсан үйлчилгээний VPC бүгд attachment хэлбэрээр харагдана. Түүнд өөрийн route хүснэгтүүд байх бөгөөд аль attachment өгөгдсөн prefix-ийг авахыг тэд сонгоно.

Төвлөрсөн гарцыг энэ төв л боломжтой болгодог: VPN нэг attachment болж бууж, гарцын VPC нөгөө болж буух ба transit gateway-ийн route хүснэгт интернет рүү чиглэсэн prefix-үүдийг эхнийхээс хоёр дахь руу илгээдэг. virtual private gateway-тай үед илгээх хоёр дахь attachment байхгүй тул загварыг дараа нь засаж янзалж болохгүй.

Дэмжигдсэн гарцын зам, hop бүрээр

Лавлах загварт таван hop байх ба сум бүр таны тохируулах routing шийдвэр юм. Урсгал локал сүлжээнээс Site-to-Site VPN attachment руу гарч, transit gateway-ийн хүснэгт түүнийг гарцын VPC attachment руу дамжуулж, тэнд subnet хүснэгт нийтийн NAT gateway руу илгээдэг. NAT gateway эх хаягийг орчуулж, internet gateway пакетыг гадагш гаргана.

On-premises network
  -> Site-to-Site VPN attachment on the transit gateway
  -> transit gateway route table
  -> egress VPC attachment
  -> public NAT gateway in that VPC
  -> internet gateway

Сүүлийн hop-ууд ажиллах эсэхийг хоёр зүйл шийднэ. NAT gateway нь нийтийн байх ёстой, elastic IP болон internet gateway руу route-тай байх ёстой, учир нь хувийн NAT gateway сүлжээнүүдийн хооронд орчуулдаг бөгөөд хэзээ ч интернетийн гарц болдоггүй.

Үйлчлэхээр төлөвлөж буй Availability Zone бүрт нэг NAT gateway төлөвлөж, subnet хүснэгт бүр орон нутгийнхаа руу заана. Тэмдэглэлдээ transit gateway-ийн хүснэгт болон VPC-ийн хүснэгтүүдийг тусдаа объект болгон хадгал, учир нь нэг нь attachment, нөгөө нь VPC доторх нөөцийг сонгодог. Зөвхөн аль нэгэнд нь default route байвал замын тал нь тодорхойгүй үлдэж, холбохыг хамгийн хэцүү хэсэгчилсэн алдаа үүсдэг.

Эдгээр загварууд буцах зам дээр л бүтэлгүйтдэг

NAT gateway нь өмнө харсан урсгалуудад төлөв хадгалдаг тул гарч буй холболтын хариу шинэ орж ирэх дүрэмгүй буцдаг. Энэ шинж чанар локал үйлчилгээг интернетэд нийтэлдэггүй бөгөөд тэгж нийтэлдэг мэт хандах нь баг нэг өдрийг хэзээ ч үүсэхгүй байсан холболтыг дибаг хийхэд зарцуулахад хүргэдэг. Клиентээс эхэлсэн урсгалд дөрвөн route тохирох ёстой: локал бодлого, transit gateway-ийн хүснэгт, гарцын subnet хүснэгт, NAT subnet хүснэгт. Сүүлийнхийг алдвал хүсэлт барилгаас гарч, хариу AWS дотор үхнэ.

VPN-ийн ард байгаа бодит клиентээр шалгаж, ямар нийтийн эх хаяг харуулж байгааг хараарай. Хэрэв энэ нь NAT gateway-ийн elastic IP бол орчуулга хийгдэж байна; өөр зүйл бол өөр гарцыг хэмжиж байна.

Энэ алдааны тэгш бус хувилбарыг эрт таних нь зүйтэй. Нэг Availability Zone-ийн NAT subnet хүснэгтэд клиентийн prefix руу буцах route байгаа, нөгөөд байхгүй бол шинэ холболтууд урсгал аль бүсэд буухаас хамаарч амжилттай эсвэл бүтэлгүй болж, энэ хэв маягийг тогтворгүй интернет гэж буруу уншдаг. Тасалбар нээгдсэн бүсийг засахын оронд үйлчилж буй бүс бүрийн subnet хүснэгтийг харьцуул, учир нь дутуу route нь бүх алдаа бөгөөд нөгөө талд юу ч өөрчлөх шаардлагагүй.

Хэзээ ил proxy нь илүү сайн загвар вэ

Гарцын VPC-ийн инстанс дээрх HTTP proxy нь хууль ёсны хувилбар бөгөөд ихэвчлэн хямд. Клиентүүд үүнийг ашиглахаар тохируулагдаж, proxy өөрийн холболтыг гадагш нээж, буцах зам нь тэгш хэмт routing-ийн оньсого биш, түүний асуудал болдог. Цөөн програмын хувьд энэ нь transit gateway-ийн ихэнх ажлыг арилгадаг. Мөн NAT gateway үйлдвэрлэж чадахгүй хэрэглэгч тус бүрийн лог өгдөг.

Гэхдээ энэ нь ил тод биш. Proxy тохиргоог үл тоомсорлож буй бүхэн, HTTP бус протокол бүр энэ замаар явахгүй.

Сонголт нь таны програмууд яг юугаар ярьж байгаа, лог дотор хэр их таних мэдээлэл хэрэгтэйгээс хамаарна. Тэд HTTP-ээр ярьдаг газар proxy байр сууриа олно; дурын протоколд ерөнхий гарц хэрэгтэй газар AWS-ийн дэмждэг загвар нь transit gateway юм. Үүнийг урьдчилан шийдэх нь route хүснэгт баригдсаны дараа олж мэдэхээс хямд.

Холбоотой нийтлэлүүд