ทำไมกฎ split tunnel ของคุณจึงเลิกตรงกับบริการ

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

กฎกำหนดอะไรและ DNS ส่งอะไรกลับมา

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

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

สามทางที่การจับคู่แตก

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

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

อ่านปลายทางที่แอปใช้จริง

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

getent ahosts api.example.com
dig +short api.example.com A
dig +short api.example.com AAAA
ss -tnp | grep -F api
ip route get 203.0.113.40

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

ซ่อมกลไก ไม่ใช่ซ่อมอาการ

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

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

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

ตรวจสอบความตั้งใจทั้งสองครึ่ง

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

curl -sv --max-time 5 https://api.example.com/ -o /dev/null 2>&1 | grep -E 'Trying|Connected to'
curl -sS --max-time 5 https://public.example/ -o /dev/null -w '%{http_code}\n'

บันทึกที่อยู่ใหม่ กลไกที่เลือก และวันที่ บันทึกนั้นแหละที่กันไม่ให้คนถัดไปสรุปว่า VPN เพิกเฉยต่อการกำหนดค่าของตัวเองอย่างสุ่ม