คิลสวิตช์บล็อกเซิร์ฟเวอร์ VPN ก่อนที่ทราฟฟิกใดจะไหล
คิลสวิตช์บล็อกขั้นตอนไหน การค้นหาปลายทาง เส้นทางภายนอก เส้นทางขากลับ และข้อยกเว้นเพียร์ที่ล้าสมัย ด้วยตัวนับแทนการเดา
คิลสวิตช์ล้มเหลวในทิศทางที่คนไม่คาดคิด มันถูกสร้างมาเพื่อบล็อกทราฟฟิกขณะอุโมงค์ล่ม และแพ็กเก็ตที่สร้างอุโมงค์ก็คือทราฟฟิกเอง นั่นคือบั๊กทั้งหมด ชุดกฎที่ทิ้งทุกอย่างที่ไม่ผ่านอุโมงค์ก็ทิ้งแฮนด์เชกที่จะยกอุโมงค์ขึ้นด้วย ไคลเอนต์จึงลองซ้ำเป็นวงจร และข้อผิดพลาดถูกโยนให้ขั้นตอนที่ตรวจก่อน ก่อนจะขยายไฟร์วอลล์ ให้หาว่าสามขั้นตอนใดถูกปฏิเสธ การค้นหาชื่อ แพ็กเก็ตภายนอกไปยังเพียร์ หรือคำตอบที่ส่งกลับมา
อุโมงค์และทรานสปอร์ตของมันพึ่งพากันอย่างไร
อ่านไคลเอนต์ VPN เป็นสองสถานะเครือข่ายที่ใช้เส้นทางซ็อกเก็ตเดียวร่วมกัน ก่อนอุโมงค์จะมีอยู่ ไคลเอนต์เปิดซ็อกเก็ตบนอะแดปเตอร์กายภาพและส่งเฟรมที่เข้ารหัสไปยังที่อยู่และพอร์ตของเพียร์ หลังจากนั้นจึงสร้างอุปกรณ์อุโมงค์และติดตั้งเส้นทาง คิลสวิตช์คือนโยบายเกี่ยวกับสถานะที่สอง เขียนไว้กว้างจนใช้กับทั้งสองสถานะ
กฎที่อิงอินเทอร์เฟซคือรูปแบบปกติ ยอมรับสิ่งที่ออกผ่านtun0หรือwg0แล้วทิ้งเส้นทางขาออกที่เหลือ การเขียนแบบนั้นยกเว้นการเชื่อมต่อของไคลเอนต์เองกับเซิร์ฟเวอร์ไม่ได้ การใช้งานที่ถูกต้องจึงเพิ่มข้อยกเว้นนั้นอย่างชัดเจน และคุณก็ทำเช่นกันเมื่อเขียนกฎด้วยมือ กฎรายแอปบน Windows และ macOS เลี่ยงส่วนหนึ่งด้วยการจับคู่โปรเซสแทนอินเทอร์เฟซ แต่โปรเซสก็ยังต้องออกไปก่อนที่อุโมงค์จะมีอยู่
สามขั้นตอนตามลำดับที่เกิดขึ้น
ขั้นตอนแรกคือการแก้ชื่อ เมื่อโปรไฟล์เก็บชื่อโฮสต์แทนที่อยู่ตรงตัว ไคลเอนต์ต้องได้คำตอบ DNS ก่อนจะส่งอะไรได้ โปรไฟล์ที่ชี้ DNS ไปยังตัวแก้ชื่อของอุโมงค์สร้างทางตัน ตัวแก้ชื่อเข้าถึงได้ทางอุโมงค์ที่การค้นหาควรเปิดเท่านั้น การแก้ชื่อนอกอุโมงค์หรือการปักหมุดปลายทางไว้ที่ที่อยู่จะขจัดความกำกวมนี้
ขั้นตอนที่สองคือแพ็กเก็ตภายนอก ซึ่งต้องผ่านการกำหนดเส้นทางก่อนแล้วจึงผ่านไฟร์วอลล์ตามลำดับนั้น wireguard-tools จัดการครึ่งหนึ่งของการกำหนดเส้นทางนี้ให้ WireGuard โดยทำเครื่องหมายแพ็กเก็ตของตัวเองและเพิ่มกฎนโยบายให้ข้ามเส้นทางเริ่มต้นที่เพิ่งติดตั้งหน้าคู่มือของ wg-quickอธิบายกฎนั้นและตารางที่มันใช้ สร้างเส้นทางนั้นใหม่ด้วยมือ หรือปล่อยให้เครื่องมือที่สองเขียนกฎใหม่ แล้วแพ็กเก็ตที่ทำเครื่องหมายไว้อาจถูกส่งกลับเข้าไปในอุโมงค์ที่มันควรสร้าง
ขั้นตอนที่สามคือเส้นทางขากลับ แฮนด์เชกที่ไม่ได้รับคำตอบไม่ใช่หลักฐานของการทิ้งขาออก มันสอดคล้องพอ ๆ กับกฎาขาเข้าของเซิร์ฟเวอร์หรืออุปกรณ์ NAT ที่ลืมการแมป แยกสองอย่างนี้ออกจากกันก่อนจะแตะไคลเอนต์
| What you see | Stage | Where to look |
|---|---|---|
| The client log repeats a resolve step and no packets appear on the wire | 1, name lookup | Resolver path while the tunnel is down |
| The send counter on the physical adapter stays flat | 2, routing | Peer route and policy rules |
| The send counter rises and a firewall drop counter rises | 2, firewall | Rule order, mark, and interface match |
| Packets leave and nothing comes back | 3, return path | Server input rules, NAT, listening port |
ไคลเอนต์บันทึกอาการที่ตรวจพบ ไม่ใช่ขั้นตอนที่ล้มเหลว ตารางจึงมักเร็วกว่าบันทึก
ตัวนับตัดสินได้เร็วกว่าบันทึก
บน Linux,nft list rulesetหรือiptables -vnL OUTPUTพิมพ์ตัวนับแพ็กเก็ตต่อกฎ เชื่อมต่อหนึ่งครั้ง ปล่อยให้ล้มเหลว แล้วอ่านตัวนับอีกครั้ง กฎที่ตัวนับขยับคือกฎที่แฮนด์เชกชน ถ้าไม่มีอะไรขยับเลย แพ็กเก็ตไม่เคยไปถึงไฟร์วอลล์ ฉันเคยเห็นชุดกฎทิ้งแฮนด์เชกของตัวเอง และมีแต่ตัวนับที่บอกเรื่องนี้
เพื่อแยกระหว่างไม่เคยไปถึงไฟร์วอลล์กับไม่เคยออกจากโฮสต์ ให้สังเกตอินเทอร์เฟซเองip -s link show dev wlan0รายงานแพ็กเก็ตที่ส่ง และtcpdump -ni wlan0 udp port 51820แสดงเฟรม ถ้ามันแบนราบขณะไคลเอนต์ลองซ้ำ ปัญหาอยู่เหนือ netfilter ไม่มีเส้นทางไปเพียร์ กฎนโยบายชี้ไปยังอุปกรณ์ที่ยังไม่มี หรือข้อผิดพลาดซ็อกเก็ตที่ไคลเอนต์กลืนลงไป
ทดสอบข้อยกเว้นกับที่อยู่เอกสารเช่น203.0.113.10เพื่อให้ความพลาดไม่สามารถตรวจสอบโฮสต์ของคนอื่นได้
ข้อยกเว้นปลายทางที่ล้าสมัยอ่านเป็นเซิร์ฟเวอร์ล่ม
เวอร์ชันที่หลอกลวงที่สุดปรากฏหลังที่อยู่ของเพียร์เปลี่ยน บริการที่อยู่แบบไดนามิกย้ายมัน โฮสต์ถูกสร้างใหม่ หรือที่อยู่ขาออกของเครือข่ายคุณต่างออกไปข้อยกเว้นยังระบุที่อยู่เดิมแพ็กเก็ตที่ไปยังที่อยู่ใหม่จึงชนกฎทิ้ง การตั้งค่าเดิมใช้ได้เมื่อวาน จึงเป็นเหตุให้คนเริ่มตรวจสอบเซิร์ฟเวอร์
ชื่อโฮสต์ในกฎไฟร์วอลล์ช่วยคุณไม่ได้ ใน nftables ชื่อจะถูกแก้เมื่อโหลดชุดกฎ มันจึงปักหมุดที่อยู่ที่อยู่ในขณะนั้นและล้าสมัยเหมือนที่อยู่ตรงตัว ทางแก้ที่ยั่งยืนคืออัปเดตข้อยกเว้นเมื่อปลายทางเปลี่ยนและทำให้มันแคบ หนึ่งที่อยู่เพียร์ หนึ่งพอร์ตทรานสปอร์ต ช่วงที่กว้างพอจะทนการเปลี่ยนที่อยู่ก็กว้างพอจะปล่อยทราฟฟิกที่ไม่เกี่ยวข้องออกไปเช่นกัน
เมื่อคิลสวิตช์ทำงานบนโฮสต์เซิร์ฟเวอร์
การพึ่งพาแบบเดียวกันมีอยู่อีกฝั่ง และที่นั่นพลาดได้ง่ายกว่า ถ้าเครื่องที่ทำหน้าที่เป็นเซิร์ฟเวอร์ VPN ของคุณรันไคลเอนต์เดสก์ท็อปที่มีคิลสวิตช์ หรือโปรไฟล์ไฟร์วอลล์ที่คัดลอกจากแล็ปท็อปด้วย กฎทิ้งของมันก็ใช้กับบริการที่ปิดอุโมงค์ คำตอบต่อแฮนด์เชกของไคลเอนต์ถูกทิ้ง ทุกไคลเอนต์จึงเชื่อมต่อไม่ได้ในขณะที่เซิร์ฟเวอร์ดูปกติและอินเทอร์เฟซอุโมงค์ว่างอยู่
โฮสต์นั้นต้องการการยอมรับแคบ ๆ สามข้อก่อนการทิ้ง พอร์ตที่ฟังบนอินเทอร์เฟซกายภาพ อินเทอร์เฟซอุโมงค์สำหรับทราฟฟิกที่ถอดรหัสแล้ว และการส่งต่อจากอุโมงค์ไปยังสิ่งที่ไคลเอนต์ต้องเข้าถึง อ่านชุดที่ติดตั้งด้วยnft list ruleset,iptables -Sหรือpfctl -srก่อนเปลี่ยนอะไร และจำไว้ว่าชุดกฎที่บันทึกไว้อยู่รอดข้ามการรีบูต ข้อผิดพลาดตรงนั้นจึงอายุยืนกว่ากระบวนการที่สร้างมัน
ลำดับการกู้คืนที่ทำให้เครื่องยังปิดอยู่
ทำงานจากโปรไฟล์ออกไปข้างนอก อ่านที่อยู่และพอร์ตของเพียร์ที่ไคลเอนต์ใช้ ยืนยันว่าชื่อโฮสต์แก้ได้โดยไม่ต้องมีอุโมงค์ แล้วเพิ่มข้อยกเว้นหนึ่งข้อสำหรับที่อยู่และพอร์ตนั้นบนอะแดปเตอร์กายภาพเท่านั้น เชื่อมต่อใหม่และดูตัวนับการส่ง แฮนด์เชกที่สมบูรณ์คือสัญญาณว่าขั้นตอนที่สองได้รับการซ่อมแล้ว
ปล่อยนโยบายการทิ้งที่เหลือไว้ระหว่างทดสอบ การตรวจที่ไม่เป็นอันตรายคือลองเชื่อมต่อกับที่อยู่เอกสารที่ไม่เกี่ยวข้องและยืนยันว่ายังหมดเวลา ซึ่งแสดงว่าคิลสวิตช์ทำงาน ไม่ได้ถูกปิด รัดข้อยกเว้นให้แน่นเมื่ออุโมงค์เสถียร และอย่าทิ้งการอนุญาตทุกอย่างถาวรให้ไบนารีของไคลเอนต์เพียงเพราะมันสะดวก
ถ้าอุโมงค์ขึ้นแต่แอปพลิเคชันยังล้มเหลว ขั้นตอนที่เหลือไม่ใช่ขั้นนี้ DNS แยก, MTU และการกำหนดเส้นทางรายแอปแต่ละอย่างให้อุโมงค์ที่เชื่อมต่อแต่ทราฟฟิกเสีย และแต่ละอย่างมีการตรวจแรกคนละแบบ