DNS ส่วนตัวใช้งานได้ใน VPC แต่ไม่ผ่าน VPN
ชื่อส่วนตัวที่แปลงได้ภายใน EC2 แต่ไม่ผ่าน VPN คือปัญหาของเส้นทาง resolver อ่านรูปร่างของความล้มเหลวก่อนแก้ระเบียนโซน
ชื่อส่วนตัวแปลงได้จากอินสแตนซ์ EC2 แต่ไม่แปลงจากแล็ปท็อปที่เชื่อมต่อผ่าน VPN และโซนดูถูกต้องในคอนโซล ปฏิกิริยาแรกคือแก้ระเบียน ซึ่งแทบไม่เคยเป็นปัญหา ระเบียนกำลังตอบใครบางคน แต่มันไม่ได้ตอบแล็ปท็อปของคุณ สิ่งที่ต่างกันระหว่างผู้เรียกสองรายคือ resolver ที่พวกเขาถาม และว่า resolver นั้นมีเส้นทางที่รองรับเข้าสู่มุมมอง DNS ของ VPC หรือไม่
ผมเริ่มด้วยการพิสูจน์ว่าระเบียนมีอยู่จริง แล้วใช้เวลาที่เหลือไปกับเส้นทางของคำถาม ทั้งสองเป็นระบบแยกกันและล้มเหลวคนละแบบ
อ่านรูปร่างของความล้มเหลวก่อนจะเปลี่ยนแปลงอะไร
ผลลัพธ์สามแบบหมายถึงสามเรื่องที่ต่างกัน และคำถามเดียวแยกมันออกจากกัน รัน dig สำหรับชื่อกับ resolver ที่ไคลเอนต์ใช้จริง
| What you see | What it usually means | First thing to check |
|---|---|---|
| SERVFAIL, or a timeout after several seconds | No path to the resolver, or the resolver cannot reach AWS | Route to the endpoint and the security policy on port 53 |
| NXDOMAIN from a resolver that did answer | The resolver replied, but the zone is not in its view | Zone association or the forwarding rule for that namespace |
| A public address for an internal name | Split DNS is not in effect for this client | Which resolver the client is configured to use |
การหมดเวลาคือข้อความเกี่ยวกับเครือข่าย NXDOMAIN คือข้อความเกี่ยวกับมุมมอง DNS คำตอบสาธารณะคือข้อความเกี่ยวกับนโยบาย การแก้ระเบียนโซนขณะที่มีการหมดเวลาคือการทิ้งหลักฐานที่มีประโยชน์เพียงชิ้นเดียวในเคส
ทำไมที่อยู่บวกสองของ VPC ไม่ใช่ resolver ระยะไกล
ที่อยู่ CIDR บวกสองเป็นบริการภายในสำหรับทรัพยากรใน VPC AWS ระบุว่าการส่งต่อคำถามจากเครือข่ายภายในองค์กร หรือจากเซิร์ฟเวอร์ DNS ของ VPC อื่น ไปยังที่อยู่นั้นโดยตรงไม่ได้รับการรองรับและอาจให้ผลลัพธ์ที่ไม่เสถียร
นั่นไม่ได้หมายความว่าการทดลองจะไม่เคยดูเหมือนได้ผล มันหมายความว่าพฤติกรรมไม่ใช่สัญญาที่จะใส่ในสคริปต์ช่วยเหลือได้ ทิศทางที่รองรับคือ Resolver endpoint ขาเข้า ซึ่งเป็นคู่ที่อยู่ใน VPC ของคุณ เข้าถึงได้จากเครือข่ายที่คุณควบคุม และรับคำถามที่มาจากนอก AWS
สร้างเส้นทางตามลำดับที่ล้มเหลวอย่างสะอาด
ต้องมีสามฮอป และแต่ละฮอปมีวิธีล้มเหลวของตัวเอง
VPN client -> approved DNS forwarder
forwarder -> forwarding rule for internal.example
forwarding rule -> Resolver inbound endpoint addressesตัวส่งต่อต้องมีเส้นทางไปยังที่อยู่ของ endpoint ผ่าน VPN และเส้นทางขากลับก็ต้องทำงานด้วย สำหรับ DNS ปกติบนพอร์ต 53 endpoint ตอบผ่าน UDP และ TCP ดังนั้นทั้งสองโปรโตคอลต้องได้รับอนุญาต และทั้งสองต้องผ่านการตรวจสอบสถานะใด ๆ ที่อยู่ตรงกลาง
จากนั้นตรวจมุมมอง DNS แยกต่างหาก โซนโฮสต์ส่วนตัวมองเห็นได้เฉพาะ VPC ที่เชื่อมโยงอยู่ หรือผ่านข้อตกลงการแชร์ที่ตั้งใจไว้ endpoint ที่เข้าถึงได้ไม่ได้ทำให้ทุกโซนส่วนตัวแปลงได้เองในบริบทการแปลงของมัน
endpoint ขาออกให้บริการทิศทางตรงกันข้ามและจะไม่ตอบคำถามที่เข้ามาจากแล็ปท็อปของคุณ
ตรวจสอบจากทั้งสองปลาย
ถามจากไคลเอนต์ไปยังตัวส่งต่อ แล้วจากตัวส่งต่อไปยัง endpoint หากไคลเอนต์ล้มเหลวขณะตัวส่งต่อสำเร็จ ช่องว่างอยู่ระหว่างสองตัวนั้น
หากทั้งสองล้มเหลว ให้ดูนโยบายความปลอดภัยบน endpoint และที่อยู่ต้นทางที่มันเห็นจริง ตัวส่งต่อที่อยู่หลัง NAT จะแสดงที่อยู่ NAT แทนที่อยู่ VPN ของแล็ปท็อป และความต่างเพียงเท่านี้ก็พอที่จะทำให้คำถามถูกทิ้ง หากทั้งสองสำเร็จแต่แอปพลิเคชันยังล้มเหลว แอปพลิเคชันอาจใช้ resolver อื่นที่ไม่ใช่อันที่คุณทดสอบ
แยกเนมสเปซสาธารณะและส่วนตัวออกจากกันโดยตั้งใจ Split DNS คือนโยบายที่คุณกำหนด ไม่ใช่ผลข้างเคียงของการค้นหาหนึ่งครั้งที่บังเอิญคืนข้อมูล
สิ่งที่ผมจะไม่ทำ
ผมจะไม่เพิ่มกฎ NAT ที่ทำให้การค้นหาหนึ่งครั้งได้ผลแล้วเรียกมันว่าการออกแบบ
ผมจะไม่ชี้ไคลเอนต์ระยะไกลทุกตัวไปที่ที่อยู่บวกสองเพียงเพราะการทดสอบครั้งหนึ่งเคยคืนระเบียน และผมจะไม่ขยายนโยบายความปลอดภัยของ endpoint ไปทั้งพูล VPN เมื่อตัวส่งต่อเพียงตัวเดียวต้องการการเข้าถึง หากองค์กรมีตัวส่งต่อที่ได้รับอนุมัติอยู่ใน VPC แล้ว ให้อ่านการออกแบบนั้นก่อน เพราะ endpoint ตัวที่สองที่คุณเพิ่มคือตัวที่ไม่มีใครบันทึกไว้