DNS เชิงภูมิศาสตร์และ anycast: การตรวจสอบทางเข้า VPN ที่คุณได้รับ

ใกล้ ๆ คำตอบ DNS ดูเหมือนปัญหาที่แก้แล้ว จนกว่าการเชื่อมต่อจะไปลงที่อื่น DNS เชิงภูมิศาสตร์ และ anycast ต่างพยายามย่อเส้นทาง และตัดสินใจเรื่องนั้นจากข้อมูลที่ต่างกัน ทั้งสองไม่ได้ยืนยันว่าประตูที่คุณไปถึงเข้าถึงได้ มันแสดงตัวตนที่ไคลเอนต์ของคุณคาดหวัง หรือเซสชันของคุณอยู่รอดเมื่อโหนดเปลี่ยน การตรวจสอบด้านล่างแยกสี่คำถามนั้น

ตรวจสอบว่า รีโซลเวอร์ รายงานตำแหน่งของใครจริง ๆ

เซิร์ฟเวอร์ที่มีอำนาจตอบคำถามที่ไวต่อโทโพโลยีมักเห็นที่อยู่ของ รีโซลเวอร์ แบบเรียกซ้ำที่ถาม ไม่ใช่ที่อยู่ของคนที่พิมพ์ชื่อ รีโซลเวอร์ แบบรวมศูนย์อาจอยู่ห่างจากไคลเอนต์ที่ให้บริการ และคำตอบสะท้อน รีโซลเวอร์ ไม่ใช่พวกเขา นั่นไม่ใช่ข้อบกพร่อง นั่นคือวิธีที่โปรโตคอลทำงานเว้นแต่จะให้ข้อมูลเพิ่มเติม ข้อกำหนด EDNS Client Subnet อธิบายทั้งข้อจำกัดและวิธีแก้ไขที่เป็นทางเลือก

EDNS Client Subnet สามารถพาข้อมูลเครือข่ายต้นทางได้เมื่อผู้เข้าร่วมทุกคนรองรับและเปิดใช้งาน เป็นทางเลือก มีผลต่อความเป็นส่วนตัวและการแคช และไม่ใช่การอนุญาตให้สันนิษฐานว่า รีโซลเวอร์ สาธารณะใด ๆ รายงานตำแหน่งผู้ใช้ที่แม่นยำ ถามผู้ดำเนินการ รีโซลเวอร์ ก่อนออกแบบโดยอิงสิ่งนี้

dig +short vpn.example.com @1.1.1.1
dig +short vpn.example.com @9.9.9.9
dig +subnet=203.0.113.0/24 +short vpn.example.com

ตรวจสอบว่าเส้นทาง anycast ตัดสินใจอะไร

ด้วย anycast หลายตำแหน่งประกาศการเข้าถึงที่อยู่บริการเดียว และเครือข่ายส่งไคลเอนต์แต่ละรายไปยังโหนดที่เส้นทางของตนชอบ การเลือกนั้นทำโดย BGP และนโยบายโดยรอบ ไม่ใช่ระยะทางบนแผนที่ ความใกล้ชิดเชิงโทโพโลยีโดยทั่วไปก็ไม่ได้หมายถึงประสิทธิภาพไปกลับที่ดีกว่า เพราะเส้นทางที่ดูสั้นอาจแออัดหรือไม่สมมาตร ที่อยู่ที่คุณได้รับไม่ได้บอกอะไรเกี่ยวกับโหนดที่ตอบ

ยืนยันตำแหน่งที่ให้บริการจากฝั่งบริการ หรือจากคำตอบที่ระบุชื่อตำแหน่งนั้น ไม่ใช่จากคำตอบ DNS เพียงอย่างเดียว traceroute -n 198.51.100.20 แสดงเส้นทางที่คุณใช้และยังไม่ระบุชื่อโฮสต์ที่ปลายทาง ดังนั้นอ่านเป็นเส้นทางไม่ใช่คำตอบ

ตรวจสอบว่าเซสชันอยู่รอดเมื่อโหนดเปลี่ยน

คำถาม DNS สั้นและเซสชัน VPN ยาว ทั้งสองมีความต้องการสถานะที่แตกต่างกันโดยสิ้นเชิง เส้นทางอาจเปลี่ยนกลางเซสชัน และเมื่อเป็นเช่นนั้น แพ็กเก็ตภายหลังอาจมาถึงโหนดที่ไม่เคยเห็นอุโมงค์ของคุณ การที่มันอยู่รอดได้หรือไม่ขึ้นอยู่กับการนำไปใช้ สถานะที่แบ่งปัน การเชื่อมต่อใหม่โดยเจตนา หรือความล้มเหลวที่บันทึกไว้ ที่อยู่เพียงอย่างเดียวไม่ได้ให้สิ่งใดในนั้น

สังเกตการเปลี่ยนแทนที่จะสันนิษฐาน sudo tcpdump -ni any -c 20 esp แสดงแพ็กเก็ตภายนอกเมื่อเส้นทางเปลี่ยน และการเปลี่ยนที่อยู่ของเพียร์อย่างกะทันหันคือการเปลี่ยนที่เกิดขึ้น กำหนดพฤติกรรมที่ต้องการอย่างชัดเจนสำหรับการนำไปใช้ที่คุณรัน แล้วทดสอบโดยบังคับให้เส้นทางเปลี่ยน หากการออกแบบสันนิษฐานการทำสำเนาเซสชัน ให้ระบุกลไกและระบุความล้มเหลวที่มันไม่ครอบคลุม

ตรวจสอบว่าตัวตนยังตรงกัน

จุดเข้าทุกจุดต้องแสดงตัวตนที่โปรไฟล์ไคลเอนต์ของคุณคาดหวัง ใบรับรองที่ออกสำหรับชื่อบริการใช้ได้ข้ามโหนด ขณะที่ใบรับรองต่อโหนดบังคับให้ไคลเอนต์ยอมรับสิ่งใหม่ และนั่นคือที่ที่ผู้ใช้เรียนรู้ที่จะคลิกผ่านคำเตือน รักษาตัวตนที่คาดหวังและโปรไฟล์ให้สอดคล้องกับโมเดลการเข้า

ตรวจสอบจากไคลเอนต์ที่ไปถึงโหนดผิดปกติ เพราะนั่นคือกรณีที่ใบรับรองต่อโหนดปรากฏขึ้น openssl s_client -connect vpn.example.com:443 -servername vpn.example.com พิมพ์ห่วงโซ่และชื่อ ซึ่งเป็นสิ่งที่ไคลเอนต์เปรียบเทียบ จากนั้นตัดสินใจว่าควรจำกัดโปรไฟล์หรือเปลี่ยนโมเดลใบรับรอง

ตรวจสอบบันทึก ไม่ใช่แค่คำตอบแรก

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

dig +short vpn.example.com
getent hosts vpn.example.com
curl -s -o /dev/null -w "%{http_code}
" https://vpn.example.com/health

รันสถานการณ์จากเครือข่ายการเข้าถึงที่เป็นตัวแทน ไม่ใช่แค่จากสำนักงาน เพราะคำถามทั้งหมดคือจุดเข้าใดที่ไคลเอนต์ต่าง ๆ เข้าถึงจริง เครือข่ายเดียวคือตัวอย่างของหนึ่ง