การกำหนดเส้นทาง VPN ตามโดเมนเทียบกับเส้นทาง IP: แบบไหนเหมาะ?
ชื่อโฮสต์ในช่องสปลิตทันเนลไม่ใช่เส้นทาง เปรียบเทียบกฎโดเมนและคำนำหน้าที่ชัดเจนในด้านการรีเฟรช ขอบเขตซับโดเมน และสิ่งที่เกิดขึ้นเมื่อ DNS เปลี่ยน
เส้นทาง IP จับคู่กับคำนำหน้าแอดเดรส และเคอร์เนลนำไปใช้โดยไม่ถามคำถามเพิ่มเติม กฎ VPN ที่อิงโดเมนจับคู่กับชื่อ ซึ่งหมายความว่ามีบางอย่างในสแตกต้องตัดสินใจว่าชื่อนั้นหมายถึงแอดเดรสใดในขณะนี้ และทำให้การตัดสินใจนั้นเป็นปัจจุบันอยู่เสมอ สิ่งเหล่านี้เป็นกลไกต่างกันที่มีรูปแบบความล้มเหลวต่างกัน และผู้ขายใช้คำเดียวกันกับทั้งสองแบบ การเปรียบเทียบในรายการฟีเจอร์พลาดประเด็น ควรเปรียบเทียบจากสิ่งที่เกิดขึ้นเมื่อคำตอบเปลี่ยน
การแบ่งที่เป็นประโยชน์คือระหว่างกฎที่แก้ชื่อกับกฎที่ไม่แก้ชื่อ
แต่ละกฎจับคู่กับอะไรจริง ๆ
กฎคำนำหน้าจับคู่กับแอดเดรสปลายทางในตารางเส้นทาง ไม่มีอะไรถูกแก้ ไม่มีอะไรหมดอายุ และการจับคู่แม่นยำสำหรับทุกแพ็กเก็ต กฎโดเมนจับคู่กับคำขอชื่อจากแอปพลิเคชัน ซึ่ง RFC 1034 นิยามว่าเป็นต้นไม้ของป้ายกำกับไม่ใช่แอดเดรส ผลิตภัณฑ์บางตัวแก้ชื่อเพียงครั้งเดียวแล้วติดตั้งแอดเดรสที่ได้เป็นเส้นทาง ซึ่งทำให้กฎกลายเป็นกฎ IP ที่มีตัวจับเวลารีเฟรชติดอยู่
รู้ก่อนดีบักว่าคุณมีแบบไหนในสองแบบนี้ เพราะความล้มเหลวดูแตกต่างกันอย่างสิ้นเชิงในแต่ละกรณี
กฎโดเมนอยู่ในส่วนใดของสแตก
หากผลิตภัณฑ์ใช้กฎโดเมนผ่านพร็อกซีภายใน เครือข่ายต้องไปถึงพร็อกซีนั้น และแอปพลิเคชันที่เพิกเฉยต่อพร็อกซีของระบบจะข้ามกฎไปทั้งหมด หากใช้โดยการแก้ชื่อและเพิ่มเส้นทาง แอดเดรสจะสดใหม่เพียงถึงการรีเฟรชครั้งล่าสุดเท่านั้น หากเชื่อมกับตัวแก้ชื่อ พฤติกรรมของ DNS จะกลายเป็นส่วนหนึ่งของนโยบายการกำหนดเส้นทาง และตัวแก้ชื่อสำรองอาจยกเลิกได้อย่างเงียบ ๆ
อ่านโมเดลของผู้ขายไม่ใช่ป้ายของการตั้งค่า ไคลเอนต์สองรายที่มีช่องชื่อ Split Tunnel อาจกำลังทำสามสิ่งต่างกัน
เปรียบเทียบว่าอะไรพัง
สามสิ่งพังต่างกัน การเปลี่ยนแอดเดรส: ชื่อโฮสต์ CDN อาจแก้เป็นชุดแอดเดรสอื่นได้ภายในไม่กี่นาที รายการที่คัดลอกมาจึงเก่าเร็ว ขอบเขตซับโดเมน: กฎสำหรับ example.com อาจครอบคลุม api.example.com หรือไม่ก็ได้ และเอกสารมักระบุชัดว่าเป็นแบบไหน ความล้มเหลวในการแก้ชื่อ: เมื่อตัวแก้ชื่อล้มเหลว ไคลเอนต์ที่แก้ชื่ออาจหันไปทำทันเนลทราฟฟิกหรือส่งตรงแทน
มีเพียงข้อที่สองเท่านั้นที่เป็นคำถามเรื่องการตั้งค่า อีกสองข้อเป็นคำถามเรื่องการออกแบบว่าผลิตภัณฑ์ยอมเดามากแค่ไหน
| Behaviour | Prefix rule | Domain rule |
|---|---|---|
| Match basis | destination address | requested name or resolved addresses |
| Staleness | none | depends on refresh policy |
| Subdomain scope | not applicable | product-defined |
| Resolver outage | unaffected | product-defined fallback |
| Where to debug | routing table | client log plus resolver state |
เมื่อใดคำนำหน้าจึงเป็นคำตอบที่ดีกว่า
สำหรับซับเน็ตส่วนตัวที่เสถียร คำนำหน้าที่ชัดเจนกว่าจะชัดเจนกว่า เร็วกว่า และตรวจสอบง่ายกว่า อีกทั้งยังทนต่อการล่มของตัวแก้ชื่อ เพราะไม่มีอะไรต้องแก้ ใช้กฎโดเมนเมื่อบริการถูกโฮสต์ เมื่อแอดเดรสหมุนเวียน หรือเมื่อคุณไม่สามารถแจกแจงชุดปลายทางได้จริง ๆ อย่าใช้เพียงเพราะชื่อโฮสต์เป็นสิ่งที่คุณบังเอิญรู้
รายการคงที่ที่เดาเอาถือว่าแย่ที่สุดในทั้งสองแบบ: ดูเหมือนได้รับการดูแล และพลาดทราฟฟิกอย่างเงียบ ๆ ในวันที่ผู้ให้บริการเพิ่มโฮสต์
ตรวจสอบด้วยคำขอใหม่
ทดสอบด้วยคำขอเย็นหลังการเชื่อมต่อใหม่ตามปกติ เพราะหน้าเว็บที่แคชไว้อาจไม่แตะกฎเลย แก้ชื่อแล้วตรวจดูว่าการเชื่อมต่อไปที่ใดจริง ๆ dig +short app.example.com ให้ชุดแอดเดรสปัจจุบัน และรายการการเชื่อมต่อของไคลเอนต์บอกคุณว่าอินเทอร์เฟซใดพาการไหลไป
ทำซ้ำหลังจากช่วงรีเฟรชที่ผลิตภัณฑ์ระบุไว้ หากชุดแอดเดรสเลื่อนไปและกฎไม่ตาม แสดงว่าคุณพบพฤติกรรมจริงแล้ว
แยกนโยบายของตัวแก้ชื่อออกมาด้วย กฎโดเมนต้องมีข้อมูลชื่อที่ถูกต้อง แต่ไม่ได้ตัดสินใจเองว่าตัวแก้ชื่อใดตอบคำถาม