กฎโดเมนของ VPN พังเมื่อ CDN เปลี่ยนที่อยู่

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

ทำไมการค้นหาหนึ่งครั้งจึงไม่ใช่บัญชีรายการ

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

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

ช่องว่างที่สามคือตระกูลที่อยู่ กฎสำหรับ v4 อย่างเดียวไม่บอกอะไรเกี่ยวกับระเบียน AAAA ที่ไคลเอนต์อาจต้องการ

สามเงื่อนไขที่ตัดสินกฎโดเมนหรือช่วง

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

ข้อสอง กลไกโดเมนของไคลเอนต์คุณรีเฟรชหรือไม่ กฎที่แก้ครั้งเดียวตอนเชื่อมต่อและไม่แก้อีกเลยคือภาพ ณ ขณะหนึ่งที่มีแบรนดิ้งดีกว่า ข้อสาม กลไกนั้นครอบโดเมนย่อยและทั้งสองตระกูลที่อยู่ หรือเฉพาะชื่อที่คุณพิมพ์

ตอบสามข้อนั้นแล้วตัวเลือกมักชัดเจน การเดาสร้างกฎที่ใช้ได้ในการทดสอบและล้มเหลวในการใช้งานจริง

ทดสอบเซสชัน ไม่ใช่หน้าเว็บ

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

ระบุสิ่งที่เซสชันติดต่อจริง แทนสิ่งที่หน้าเว็บแสดง:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

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

แต่ละกลไกครอบคลุมอะไรจริง

กลไกทั้งสองดูเหมือนสลับกันได้ในหน้าการตั้งค่า และทำงานต่างกันข้างใน

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

ไม่มีอันใดเป็นซูเปอร์เซ็ตของอีกอัน นั่นคือเหตุผลที่การผสมกันโดยไม่มีบันทึกทำให้เกิดความสับสนในภายหลัง

ตรวจสอบอีกครั้งหลังบริการเปลี่ยน

หลังอัปเดตไคลเอนต์หรือบริการเปลี่ยน ให้รันการทดสอบเซสชันเดิมอีกครั้ง รายการที่อยู่ที่เคยใช้ได้เป็นหลักฐานของช่วงนั้น ไม่ใช่บัญชีรายการถาวรของโครงสร้างพื้นฐานของบริการ

จดว่ากลไกใดครอบชื่อโฮสต์ใด และวันที่ตรวจสอบครั้งล่าสุด

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