เอกสาร split-tunnel ต้องมีกฎ DNS ข้างทุกรูท
รูทตัดสินด้วยที่อยู่ รีโซลเวอร์ตัดสินด้วยชื่อ บันทึกตัวเลือกทั้งสองต่อโฟลว์ แต่ละอย่างพร้อมการทดสอบหนึ่งครั้ง ไม่อย่างนั้นบันทึกจะล้มเหลวเมื่อ DNS เปลี่ยน
บันทึก split-tunnel ที่กล่าวว่า "ทราฟฟิกสำนักงานผ่าน VPN" ได้บันทึกการตัดสินใจหนึ่งอย่างและบอกเป็นนัยอีกสามอย่าง ในชั้นแพ็กเก็ต ตารางเส้นทางเลือกอินเทอร์เฟซตามที่อยู่ปลายทาง ในชั้นชื่อ รีโซลเวอร์เลือกเซิร์ฟเวอร์ตามคำถาม และตัวเลือกทั้งสองทำอย่างเป็นอิสระต่อกัน นั่นคือเหตุผลที่คำนำหน้าที่บันทึกไว้อย่างถูกต้องยังสามารถสร้างเครื่องที่แปลงชื่อภายในเป็นที่อยู่สาธารณะ หรือไม่แปลงอะไรเลยในขณะที่รูทดูสมบูรณ์แบบ
ตัวเลือกสองอย่าง ความพยายามเชื่อมต่อหนึ่งครั้ง
เมื่อแอปพลิเคชันเชื่อมต่อกับ files.corp.example จะมีการค้นหาสองครั้งก่อนที่แพ็กเก็ตจะเกิดขึ้น รีโซลเวอร์ตัดสินว่าเซิร์ฟเวอร์ใดได้รับคำถาม โดยใช้โดเมนค้นหา โดเมนเส้นทางต่อลิงก์ หรือกฎโปรไฟล์ที่ชัดเจน จากนั้นตารางเส้นทางตัดสินว่าที่อยู่ที่ได้จะไปที่ใด โดยใช้การจับคู่คำนำที่ยาวที่สุดกับปลายทาง
ไม่มีสิ่งใดเชื่อมโยงการตัดสินใจทั้งสองนั้น โซนส่วนตัวสามารถตอบด้วย 10.20.4.11 ในขณะที่ตารางเส้นทางส่ง 10.20.0.0/16 เข้าไปในอุโมงค์ และการเชื่อมต่อทำงานได้ พลิกอย่างใดอย่างหนึ่งแล้วมันล้มเหลวในแบบที่ดูเหมือนอีกอย่างหนึ่ง: นโยบาย DNS ที่ถูกต้องบวกเส้นทางที่หายไปให้ชื่อที่แปลงแล้วและการหมดเวลา ในขณะที่เส้นทางที่ถูกต้องบวกรีโซลเวอร์สาธารณะให้ที่อยู่ที่ถูกส่งไปยังที่ผิดอย่างสะอาด
DNS แบบขอบฟ้าแบ่งทำให้เรื่องนี้คมขึ้น ชื่อเดียวกันสามารถคืนที่อยู่ส่วนตัวจากรีโซลเวอร์ภายในและที่อยู่สาธารณะจากตัวที่หันสู่อินเทอร์เน็ต ดังนั้นบันทึกที่บันทึกเพียงคำนำไม่สามารถคาดการณ์ได้ว่าลูกค้าจะใช้ที่อยู่ใดจริง ๆ เขียนเส้นทางของรีโซลเวอร์ลงไป ไม่อย่างนั้นที่อยู่ก็เป็นการเดา
บันทึกที่มีแต่รูทละอะไรไว้
บันทึกที่มีแต่รูทใช้ไม่ได้กับความล้มเหลวที่พบบ่อยที่สุดของ split-tunnel: ชื่อ ผู้ใช้รายงานว่า อินทราเน็ตโหลดไม่ขึ้น อุโมงค์ทำงานอยู่ และคำนำก็มีอยู่ ผู้ที่รับตั๋วไม่มีบันทึกว่ารีโซลเวอร์ใดควรตอบ ไม่มีวิธีแยกคำต่อท้ายการค้นหาที่ผิดออกจากเซิร์ฟเวอร์ที่ถูกบล็อก และไม่มีเส้นฐานให้เปรียบเทียบ
การละเลยอย่างที่สองคือรายการข้อยกเว้น การออกแบบ split-tunnel ถูกกำหนดพอ ๆ กับสิ่งที่อยู่ภายนอกอุโมงค์และสิ่งที่เข้ามาข้างใน และช่วงที่ถูกยกเว้นมักเป็นสิ่งที่แตกก่อน เพราะเส้นทางภายในที่เฉพาะเจาะจงกว่าหรือตัวกรองฝั่งลูกค้าสามารถลบล้างเจตนาได้โดยไม่ต้องแตะโปรไฟล์
อย่างที่สามคืออีกด้านไกลของอุโมงค์ เส้นทางฝั่งลูกค้าเพียงวางแพ็กเก็ตลงบนสายเท่านั้น เกตเวย์ยังต้องส่งต่อและมีเส้นทางกลับ คู่มือ การส่งต่อ ของ strongSwan เตือนว่ากฎการส่งต่อและไฟร์วอลล์บนเกตเวย์เป็นส่วนหนึ่งของฟีเจอร์ ไม่ใช่ส่วนของงานประปาที่คุณถือว่าเป็นเรื่องแน่นอนได้
เขตข้อมูลที่ทำให้บันทึกนำไปปฏิบัติได้
หนึ่งแถวต่อโฟลว์ และโฟลว์คือปลายทางบวกชื่อบวกเจ้าของ นี่คือเขตข้อมูลที่อยู่รอดเมื่อเผชิญกับเหตุการณ์จริง:
| Field | Why it has to be written down |
|---|---|
| Destination prefix and address family | The route is per family; an IPv4 note says nothing about a AAAA answer |
| Selected tunnel or direct path | Names the decision, not the symptom |
| Private namespace and resolver | Which domain, which server, which search suffix |
| Public name path | Confirms public names do not accidentally use the private resolver |
| Where the rule lives | Client profile, server push, OS policy or management tool |
| Owner and review date | Namespaces change owner more often than routes change |
แถว "มันอาศัยอยู่ที่ไหน" คือแถวที่ผู้คนข้ามไป คำนำที่เซิร์ฟเวอร์ผลักมา เส้นทางที่โปรไฟล์ลูกค้าเพิ่ม และเส้นทางที่พิมพ์ในเชลล์ต่างกันที่ใครสามารถเปลี่ยนได้และมันอยู่รอดหลังเชื่อมต่อใหม่หรือไม่ หากไม่มีเขตข้อมูลนั้น วิศวกรคนต่อไปจะบอกไม่ได้ว่ากำลังดูอันไหนในสามอัน
หนึ่งการทดสอบต่อกฎ ไม่ใช่ต่ออุโมงค์
แต่ละแถวต้องการการตรวจสอบที่ไม่เป็นอันตรายสองอย่าง: อย่างหนึ่งฝึกเส้นทาง อีกอย่างฝึกชื่อ สำหรับเส้นทาง ให้ขอสิ่งที่ต้องข้ามอุโมงค์และยืนยันเส้นทางแทนการเข้าถึง ตัวอย่างเช่น tracert -d 10.20.4.11 บน Windows หรือ ip route get 10.20.4.11 บน Linux สำหรับชื่อ ให้สอบถามชื่อส่วนตัวและบันทึกว่าเซิร์ฟเวอร์ใดตอบ โดยใช้ resolvectl query files.corp.example หรือ dig files.corp.example กับรีโซลเวอร์ที่บันทึกระบุ
เพิ่มความคาดหวังเชิงลบด้วย: ควรเกิดอะไรขึ้นเมื่ออุโมงค์ปิดลง แอปพลิเคชันที่ถูกยกเว้นบนอุปกรณ์ Android หรือ iOS ที่เปิดการบล็อกโดยไม่มี VPN อาจไม่มีการเชื่อมต่อเลย และไคลเอนต์เดสก์ท็อปอาจปล่อยให้แอปเดียวกันทำงานได้ในขณะที่อุโมงค์กำลังเชื่อมต่อใหม่ การบันทึกคำตอบที่ตั้งใจไว้เปลี่ยน "VPN ทำให้แอปของฉันพัง" ให้เป็นข้อความที่ตรวจสอบได้
เก็บบันทึกไว้กับการกำหนดค่า
เก็บบันทึกไว้ข้างโปรไฟล์ที่มันอธิบายและกำหนดเวอร์ชันพร้อมโปรไฟล์นั้น เอกสารในวิกิที่ไม่มีใครอัปเดตเป็นเพียงข่าวลือ ตารางในที่เก็บเดียวกับเส้นทางที่ถูกผลักและนโยบายรีโซลเวอร์สามารถตรวจทานได้ในการเปลี่ยนแปลงเดียวกัน
เมื่อมีสิ่งใดพัง ให้เปรียบเทียบเส้นทางที่ใช้อยู่และรีโซลเวอร์ที่มีผลกับบันทึกก่อนเพิ่มข้อยกเว้นอีกข้อ สาเหตุทั่วไปสามข้อมีสองข้อ — กฎเนมสเปซเก่าและโปรเซสช่วยเหลือที่อยู่นอกนโยบายแอป — ดูเหมือนความผิดพลาดของ VPN อย่างยิ่งและมองไม่เห็นหากบันทึกแสดงเพียงคำนำ
ก่อนจะกล่าวว่าบันทึกเสร็จสมบูรณ์ ให้ยืนยันว่ามันตอบคำถามเหล่านี้เป็นลายลักษณ์อักษร: คำนำใด สำหรับตระกูลที่อยู่ใด เนมสเปซส่วนตัวใด ตอบโดยรีโซลเวอร์ใด ชื่อใดที่ตั้งใจให้คงเป็นสาธารณะ แต่ละกฎกำหนดค่าไว้ที่ใดและใครเป็นเจ้าของ และคำสั่งเดียวที่พิสูจน์เส้นทางกับคำสั่งที่พิสูจน์ชื่อ หากขาดสิ่งใดไป เหตุการณ์ครั้งต่อไปจะถูกวินิจฉัยตั้งแต่ต้น