DNS บน AWS Client VPN: ใช้ resolver ของ VPC ไม่ใช่ subnet

endpoint อยู่ใน 10.0.8.0/24 ดังนั้น resolver ต้องเป็น 10.0.8.2 นี่คือเหตุผลที่ได้ยินบ่อยที่สุด และผิดสองครั้ง Route 53 Resolver ตอบบนช่วง IPv4 หลักของ VPC บวกสอง ซึ่งสำหรับ VPC 10.0.0.0/16 คือ 10.0.0.2 ไม่ว่า endpoint จะใช้ subnet ใด ข้อผิดพลาดที่สองเงียบกว่า: การใส่ที่อยู่ที่ถูกต้องใน endpoint ไม่ได้หมายความว่าระบบปฏิบัติการของไคลเอนต์จะถามมันเลย ข้อผิดพลาดทั้งสองให้อาการเดียวกัน: การแปลงชื่อทำงานกับไคลเอนต์บางรายและล้มเหลวกับรายอื่น

ตำนานเริ่มจากความเชื่อมโยงของ subnet

ความเชื่อมโยงเกี่ยวกับตำแหน่งของ elastic network interfaces สำหรับการเชื่อมต่อไคลเอนต์ ไม่ใช่เกี่ยวกับที่อยู่ resolver ที่มีอยู่ subnet ของ endpoint ให้ที่อยู่แก่ไคลเอนต์ภายใน VPC และแต่ละ subnet ไม่ได้มี resolver ของตัวเอง

เมื่อแยกสองแนวคิดนี้ออก การคำนวณก็ไม่ลึกลับอีกต่อไป และการแก้ปัญหาก็ย้ายไปที่ไคลเอนต์ ซึ่งกรณีเหล่านี้ส่วนใหญ่จบลงจริง

คำนวณที่อยู่จากช่วงหลักของ VPC

นำ CIDR IPv4 หลักของ VPC บวกสองเข้ากับที่อยู่เครือข่าย 10.0.0.0/16 ให้ 10.0.0.2 172.31.0.0/16 ให้ 172.31.0.2 และ VPC ที่มีช่วงรองจะเก็บ resolver ไว้บนช่วงหลัก subnet 10.0.8.0/24 ภายใน VPC นั้นไม่ทำให้เปลี่ยน เขียนที่อยู่ข้าง VPC ID ก่อนแตะ endpoint เพราะตัวเลขเป็นคุณสมบัติของ VPC ไม่ใช่ของการเชื่อมต่อ

VPC ยังตอบบนที่อยู่ link-local 169.254.169.253 ที่อยู่นั้นเข้าถึงได้จากภายใน VPC แต่ไม่ใช่ปลายทางที่ถูกกำหนดเส้นทางทั่วไปสำหรับแล็ปท็อปที่อยู่อีกด้านของอุโมงค์

ดังนั้นจึงมีที่อยู่ resolver ที่ใช้ได้สองที่ และไม่มีที่ใดเป็น subnet บวกสอง

สิ่งที่การตั้งค่า endpoint ทำและไม่ทำ

endpoint ของ Client VPN มีช่องเซิร์ฟเวอร์ DNS และที่คอนโซลเสนอตัวเลือก resolver ของ VPC ก็เติมแนวคิดเดียวกัน การตั้งค่าเหล่านี้เปลี่ยนสิ่งที่บริการส่งให้ไคลเอนต์ระหว่างการเชื่อมต่อ ไม่ได้เปลี่ยนสิ่งที่ไคลเอนต์ OpenVPN ที่ไม่ได้จัดการทำกับค่านั้น เพราะไคลเอนต์ยังต้องนำไปใช้กับระบบปฏิบัติการ ช่องว่างนี้คือที่มาของ «ใช้ได้บน Mac ของฉันแต่ไม่ใช่บนเครื่อง Linux»

บน Linux การรวม resolver เป็นของตัวจัดการการเชื่อมต่อ ไม่ใช่ของผู้ใช้ การแก้ไข /etc/resolv.conf ด้วยมือพิสูจน์ว่าที่อยู่ใช้ได้ในหนึ่งเซสชันแล้วหายไปเมื่อเชื่อมต่อใหม่ นี่คือเหตุผลที่เคสที่แก้แล้วจำนวนมากกลับมาอีกในเช้าวันถัดไป

ตรวจสอบ resolver ที่ใช้งานอยู่บนไคลเอนต์หลังเชื่อมต่อ ไม่ใช่หน้าการตั้งค่าของ endpoint

split tunneling อาจทำให้ resolver ที่ถูกต้องล้มเหลว

ด้วย split tunneling จะใช้เฉพาะเส้นทางที่ถูกดันเข้าอุโมงค์ หากที่อยู่ resolver ไม่ถูกครอบคลุมด้วยเส้นทาง คำถามจะออกผ่านอินเทอร์เฟซภายในและเราเตอร์ที่บ้านตอบแทน ที่อยู่ใน endpoint ยังถูกต้องและการค้นหายังล้มเหลว เพิ่มเส้นทางสำหรับ resolver แล้วทดสอบอีกครั้ง

ช่วงภายในที่ทับซ้อนกันให้ผลลัพธ์เดียวกันในแบบที่น่ารำคาญกว่า: คำถามได้รับคำตอบ แต่มาจากเซิร์ฟเวอร์ผิดตัว

อย่าเปิด security groups สำหรับที่อยู่ Amazon DNS

สัญชาตญาณเมื่อการค้นหาหมดเวลาคือเพิ่มกฎที่อนุญาต UDP 53 ไปยังที่อยู่ resolver AWS ระบุว่า security groups และ network ACL ไม่กรองทราฟฟิก Amazon DNS เหมือนที่กรองทราฟฟิกไปยัง DNS อินสแตนซ์ของคุณเอง การเปิดกฎเหล่านั้นไม่เปลี่ยนอะไรสำหรับ resolver ของ VPC และขยายขอบเขตโดยไม่มีเหตุผล resolver ที่คุณดูแลเองเป็นอีกกรณีและต้องการกฎของตัวเองจริง ๆ

หากทั้งสองอย่างปรากฏในการออกแบบของคุณ ให้ตรวจสอบว่าไคลเอนต์ชี้ไปที่ใดจริง ๆ ก่อนแก้ไขกฎใด ๆ

ตรวจสอบเส้นทาง แล้ววัดสิ่งอื่น

แปลงชื่อสาธารณะ แปลงชื่อส่วนตัวที่ลงทะเบียนในโซนโฮสต์ส่วนตัวที่เชื่อมโยงกับ VPC และอ่าน resolver ที่ใช้งานอยู่ของไคลเอนต์ระหว่างสองอย่าง ลำดับนี้แยก «ที่อยู่ resolver ผิด» ออกจาก «โซนไม่ได้เชื่อมโยง» และ «ไคลเอนต์เพิกเฉยต่อการตั้งค่า» แต่ละอย่างมีวิธีแก้ต่างกัน และไม่มีอย่างใดเป็นปัญหาทราฟฟิก

การค้นหาที่สำเร็จไม่ได้บอกอะไรเกี่ยวกับความเร็วการถ่ายโอนที่ต่อเนื่อง ดังนั้นแยกสองเรื่องนี้ไว้เมื่อรายงาน