คิลสวิตช์หลังเปลี่ยนจาก Wi-Fi ไป cellular: อะไรพัง

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

ไม่มีอะไรบนหน้าจอแยกสามสถานะนั้นออกจากกัน จึงควรถามว่าระเบียบผูกไว้กับตัวระบุใด ไม่ใช่ถามว่าไฟแสดงสีอะไร บน Linux ระเบียบหนึ่งสามารถระบุชื่ออินเทอร์เฟซหรือ ipset ที่เติมมาจากอินเทอร์เฟซนั้นได้ บน Android สามารถบอก VpnService ว่าควรตามเครือข่ายพื้นฐานใดผ่าน setUnderlyingNetworks การผูกแต่ละอย่างชี้ไปที่ลิงก์ที่กำลังจะถูกแทนที่ และแต่ละอย่างต้องประเมินใหม่หลังจากนั้น

การเปลี่ยนผ่านเขียนอะไรใหม่จริง ๆ

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

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

สร้างอุโมงค์ด้านนอกใหม่โดยไม่เจาะรู

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

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

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

ip route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

เมื่อลิงก์ใหม่นำ IPv6 มาแต่ระเบียบไม่ได้นำมา

เครือข่ายมือถือและเครือข่ายแขกมักแจกพรีฟิกซ์ IPv6 แบบทั่วโลก แม้เมื่อ LAN แบบมีสายของออฟฟิศไม่เคยทำเช่นนั้น นโยบายที่เขียนเป็นระเบียบ IPv4 เท่านั้น ซึ่งเป็นรูปแบบเริ่มต้นของสูตร iptables และ nftables ที่ทำมือส่วนใหญ่ ก็ไม่ครอบคลุมสิ่งใดในนั้น อุโมงค์ยังเชื่อมต่ออยู่ แอปที่เข้าถึง IPv6 ได้ออกไปข้างนอก และไฟแสดงบอกความต่างไม่ได้เพราะอุโมงค์ทำงานจริง เคสกลับกันก็พบได้บ่อยพอกัน ชุดระเบียบสำหรับ IPv6 อย่างเดียวไม่ทำอะไรบนเครือข่ายที่ไม่ให้ v6

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

ip -4 route show default
ip -6 route show default
sudo nft list ruleset | grep -c 'ip6 '

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

ตัวแก้ชื่อเปลี่ยนมือกลางเซสชัน

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

อ่านตัวแก้ชื่อที่ทำงานอยู่ ไม่ใช่ตัวที่กำหนดค่าไว้ บนโฮสต์ systemd คำสั่งย่อย status แสดงว่าขอบเขตแต่ละอันมาจากลิงก์ใดและชื่อ private-DNS มีผลอยู่หรือไม่

resolvectl status --no-pager
resolvectl query intranet.example.com

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

ฝึกการเปลี่ยนผ่านและเก็บบันทึก

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

ข้อยกเว้นต้องมีรอบของตัวเอง เพราะการข้ามที่สมเหตุสมผลบนเครือข่ายเก่าไม่สมเหตุสมผลบนเครือข่ายใหม่โดยอัตโนมัติ เครื่องพิมพ์ NAS หรือ captive portal บน LAN ที่บ้านไม่มีคู่กันบนเครือข่ายมือถือ และข้อยกเว้นที่เคยไปถึงกลายเป็นระเบียบที่ไม่มีคู่กัน

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