AWS Client VPN DNS: subnet биш, VPC resolver ашигла

endpoint 10.0.8.0/24 дотор байна, тиймээс resolver нь 10.0.8.2 байх ёстой. Энэ бол хамгийн их сонсдог үндэслэл бөгөөд хоёр удаа буруу. Route 53 Resolver нь VPC-ийн үндсэн IPv4 муж дээр хоёрыг нэмсэн хаягт хариулдаг бөгөөд энэ нь 10.0.0.0/16 VPC-ийн хувьд 10.0.0.2, endpoint аль subnet ашигласнаас үл хамаарна. Хоёр дахь алдаа нь илүү чимээгүй: endpoint-д зөв хаяг тавих нь client-ийн үйлдлийн систем үүнээс хэзээ нэгэн цагт ямар нэгэн зүйл асууна гэсэн үг биш. Хоёр алдаа ижил шинж тэмдэг өгнө: нэрийн шийдэл зарим client-д ажиллаж, заримд нь бүтэлгүйтдэг.

Домог subnet-ийн холболтоос эхэлдэг

Холболт нь client-ийн холболтын уян хатан сүлжээний интерфейсүүд хаана байрладаг тухай, аль resolver хаяг байгаа тухай биш. endpoint-ийн subnet-үүд client-д VPC доторх хаяг өгдөг бөгөөд тэдгээр нь тус бүр өөрийн resolver-тэй байдаггүй.

Эдгээр хоёр санааг салгахад арифметик нууцлаг биш болж, асуудал засах ажил client рүү шилждэг, эдгээр тохиолдлын ихэнх нь үнэндээ тэнд дуусдаг.

Хаягийг VPC-ийн үндсэн мужаас тооцоол

VPC-ийн үндсэн IPv4 CIDR-ийг авч сүлжээний хаяг дээр хоёрыг нэм. 10.0.0.0/16 нь 10.0.0.2, 172.31.0.0/16 нь 172.31.0.2 өгдөг бөгөөд хоёрдогч мужтай VPC resolver-ийг үндсэн муж дээр үлдээдэг. Тэр VPC доторх 10.0.8.0/24 subnet үүнийг хөдөлгөдөггүй. endpoint-д хүрэхээс өмнө хаягийг VPC ID-ийн хажууд бич, учир нь энэ тоо нь VPC-ийн шинж, холболтын шинж биш.

VPC нь link-local 169.254.169.253 хаяг дээр ч хариулдаг. Энэ хаяг VPC дотроос хүрч болох боловч туннелийн нөгөө талд байгаа зөөврийн компьютерт ерөнхий маршрутлагдсан очих газар биш.

Тиймээс хоёр хүчинтэй resolver хаяг байгаа бөгөөд аль нь ч subnet дээр хоёрыг нэмсэн утга биш.

endpoint-ийн тохиргоо юу хийдэг, юу хийдэггүй

Client VPN endpoint-д DNS серверийн талбарууд байдаг бөгөөд консол VPC resolver-ийн сонголт санал болгодог газарт мөн адил санааг бөглөдөг. Тэдгээрийг тохируулах нь холболт тогтоох үед үйлчилгээ client-д юу дамжуулахыг өөрчилдөг. Энэ нь удирдлагагүй OpenVPN client тэр утгаар юу хийдгийг өөрчлөхгүй, учир нь client үүнийг үйлдлийн системд хэрэглэх ёстой. «Миний Mac дээр ажилладаг ч Linux машин дээр ажиллахгүй» гэдэг нь энэ зөрүүгээс гардаг.

Linux дээр resolver-ийн интеграци нь холболтын менежерт хамаарна, хэрэглэгчид биш. /etc/resolv.conf-ийг гараар засах нь хаяг нэг сессэд ажиллаж, дараа нь дахин холбогдоход алга болдгийг нотолдог — тиймээс зассан олон тохиолдол дараагийн өглөө буцаж ирдэг.

Холбогдсоны дараа client дээрх идэвхтэй resolver-ийг шалга, endpoint-ийн тохиргооны хуудсыг биш.

Split tunneling зөв resolver-ийг ялж чадна

Split tunneling үед зөвхөн туннель руу түлхсэн маршрутууд ашиглагдана. Хэрэв resolver хаяг ямар ч маршрутад хамрагдаагүй бол асуулга локал интерфейсээр гарч, гэрийн роутер чинь хариулна. endpoint дахь хаяг хэвээр зөв, хайлт хэвээр бүтэлгүйтнэ. resolver-д зориулж маршрут нэмээд дахин турш.

Давхардсан локал мужууд ижил үр дүнг илүү дургүйцэлтэйгээр өгдөг: асуулгад хариулт ирнэ, зөвхөн буруу серверээс.

Amazon DNS хаягт зориулж security group нээх хэрэггүй

Хайлт хугацаа хэтэрэх үед зөн совин resolver хаяг руу UDP 53 зөвшөөрсөн дүрэм нэмэхийг хэлдэг. security group ба сүлжээний ACL нь Amazon DNS трафикийг өөрийн DNS инстанс руу чиглэсэн трафик шиг шүүдэггүй гэдгийг AWS баримтжуулдаг. Тэдгээр дүрмийг нээх нь VPC resolver-д юу ч өөрчлөхгүй бөгөөд хил хязгаарыг шалтгаангүй өргөтгөдөг. Өөрөө ажиллуулж буй resolver нь өөр тохиолдол бөгөөд өөрийн дүрэм үнэхээр хэрэгтэй.

Хэрэв таны дизайн дээр хоёулаа байвал ямар ч дүрэм засахаас өмнө client үнэндээ аль руу чиглэж байгааг шалга.

Зам шалгаж, дараа нь өөр зүйл хэмж

Нийтийн нэрийг шийд, VPC-тэй холбогдсон хувийн хостинг зон дээр бүртгэгдсэн хувийн нэрийг шийд, тэдгээрийн хооронд client-ийн идэвхтэй resolver-ийг унш. Энэ дараалал нь «resolver хаяг буруу» гэдгийг «зон холбогдоогүй» ба «client тохиргоог үл харгалзсан» гэдгээс тусгаарлана. Тус бүр өөр засвартай бөгөөд аль нь ч дамжуулах чадварын асуудал биш.

Амжилттай хайлт нь тогтвортой дамжуулах хурдны талаар юу ч хэлдэггүй, тиймээс тайлагнахдаа энэ хоёр яриаг тусдаа байлга.