สวิตช์นิรภัยยังบล็อกทราฟฟิกแม้ VPN ตัดการเชื่อมต่อแล้ว

อุโมงค์หายไป ไอคอนเครือข่ายดูปกติ แต่ไม่มีอะไรโหลดได้ คุณตัดการเชื่อมต่อ VPN ถอนการติดตั้ง หรือรีบูต และการบล็อกที่ควรปกป้องคุณตอนการเชื่อมต่อหลุดยังตั้งอยู่ หน้าต่างไคลเอนต์อธิบายไม่ได้ เพราะไม่ใช่ไคลเอนต์ที่บล็อกคุณ: การตัดสินใจถูกเขียนลงในเคอร์เนลในนามของคุณ และไม่มีอะไรเหลือไว้ให้ลบมัน บน Windows สถานะนั้นอยู่ใน Windows Filtering Platform บน Linux มันคือชุดกฎใน iptables หรือ nftables มักมีสแนปช็อตที่ถูกนำมาใช้ซ้ำตอนบูต ต่อไปนี้คือลำดับที่ผมใช้: อ่านสถานะ ลบวัตถุที่แคบที่สุดซึ่งอธิบายความล้มเหลว แล้วหาสิ่งที่ใส่กลับซ้ำ ๆ

สวิตช์นิรภัยคือสถานะของเคอร์เนล ไม่ใช่การตั้งค่า

ไคลเอนต์เดสก์ท็อปบล็อกด้วยการเพิ่มตัวกรองที่ปฏิเสธทราฟฟิกนอกอุโมงค์ บน Windows นั่นคือตัวกรอง WFP ที่ชั้น connect-redirect และ transport และบางตัวเป็นแบบถาวร: ถูกบันทึกในที่เก็บนโยบายของ Base Filtering Engine และถูกกู้คืนเมื่อเครื่องบูต ก่อนซอฟต์แวร์ VPN ใด ๆ ทำงาน ไคลเอนต์ต่างกันที่เวลาทำความสะอาด บางตัวลบตัวกรองตอนตัดการเชื่อมต่อ บางตัวลบเฉพาะตอนปิดอย่างเรียบร้อย และบางตัวลบเฉพาะเมื่อปิดสวิตช์ก่อน ถอนการติดตั้งขณะการบล็อกยังทำงาน หรือ ฆ่าโปรเซส แล้วตัวกรองยังอยู่

สิ่งที่เทียบเท่าบน Linux คือกฎ drop หรือ reject ในเส้นทางออก บางครั้งเป็นกฎ forwarding บางครั้งเป็นนโยบายเชนที่เปลี่ยนไป กฎเหล่านั้นอยู่ได้นานกว่าโปรเซสที่เพิ่มมัน เพราะมันคือสถานะของเคอร์เนล: ฆ่าไคลเอนต์ ทำให้พัง หรือตัดไฟ แล้วเคอร์เนลยังคงทิ้งแพ็กเก็ตต่อไป โดยไม่มีอะไรเหลือไว้ให้ย้อนกลับ แพ็กเกจคงทนเพิ่มความถาวรอีกชั้นด้วยการเก็บสแนปช็อตของชุดกฎปัจจุบันและกู้คืนตอนบูต ดังนั้นการเริ่มครั้งต่อไปจะเริ่มด้วยการบล็อกที่ติดตั้งไว้แล้ว

อ่านสถานะ WFP ก่อนลบอะไร

Windows มีเครื่องมือที่คุณต้องการ เปิดพรอมป์แบบผู้ดูแลระบบและดัมป์สถานะแพลตฟอร์ม ผลลัพธ์จะมาเป็น wfpstate.xml ในไดเรกทอรีทำงาน

netsh wfp show state
netsh wfp show filters
Get-Service bfe

ค้นหาใน XML ชื่อผู้ขายที่จากไป การกระทำ Block และชั้นของตัวกรอง ตัวกรองที่ชั้น connect-redirect และ transport คือตัวที่ทำให้ทราฟฟิกปกติพัง ตัวกรองที่ชั้น receive-accept มักไม่ใช่สาเหตุของคุณ ถ้า Base Filtering Engine ไม่ทำงานเลย ให้ไปดูที่อื่น เพราะไม่มีอะไรอื่นบังคับใช้ตัวกรองเหล่านั้นได้

ตรวจสอบมุมมองไฟร์วอลล์ปกติด้วย เพราะคนส่วนใหญ่ตรวจเพียงหนึ่งในสอง:

netsh advfirewall show allprofiles
Get-NetFirewallProfile | Select-Object Name,Enabled,DefaultInboundAction

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

อ่านกฎ Linux ในไวยากรณ์ที่คุณจะใช้ลบ

iptables -S พิมพ์กฎในรูปแบบเดียวกับตอนเพิ่ม ทำให้ผลลัพธ์นำกลับมาใช้ลบได้โดยตรง iptables -L -v -n เพิ่มตัวนับแพ็กเก็ต และตัวนับนั้นบอกว่ากฎตรงกับคำขอที่ล้มเหลวของคุณจริงหรือแค่นั่งอยู่ในเชน

sudo iptables -S
sudo ip6tables -S
sudo iptables -t nat -S

อ่านนโยบายของเชน ไม่ใช่แค่กฎ: -P OUTPUT DROP บล็อกทราฟฟิกแม้ไม่มีกฎใดตรง ตรวจ IPv6 แยกต่างหาก เพราะไคลเอนต์ที่ติดตั้งทั้งสองตระกูลอาจทิ้งการบล็อก IPv6 ไว้หลังกฎ IPv4 หายไป และอาการจะขึ้นกับว่าแอปพลิเคชันชอบตระกูลใด ที่ใช้ nftables ให้รัน nft list ruleset ด้วย สองเครื่องมืออยู่ร่วมกันผ่านชั้นความเข้ากันได้ และรายการเดียวไม่จำเป็นต้องแสดงทุกกฎที่ทิ้งแพ็กเก็ตได้

ลบวัตถุที่แคบที่สุดซึ่งอธิบายความล้มเหลว

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

Get-ScheduledTask | Where-Object TaskName -like '*vpn*'
Get-Service | Where-Object DisplayName -like '*vpn*'

ตัวกรองถาวรเป็นทางสุดท้าย มันอยู่ใต้ HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent\Filter หนึ่งค่าต่อตัวกรองโดยมี GUID เป็นคีย์ ส่งออกคีย์ก่อน บันทึก GUID ที่คุณลบ ลบเฉพาะค่าที่เป็นของไคลเอนต์ที่จากไป แล้วรีบูตเพื่อให้เอนจินสร้างสถานะใหม่ อย่าลบคีย์ทั้งหมดและอย่าปิด Base Filtering Engine: Windows Firewall และ Defender พึ่งพามัน และคุณจะแลกปัญหาหนึ่งกับปัญหาที่แย่กว่า

reg export "HKLM\SYSTEM\CurrentControlSet\Services\BFE\Parameters\Policy\Persistent" C:\temp\bfe-backup.reg

บน Linux เอาแถวที่ iptables -S พิมพ์ออกมา แล้วแทน -A ด้วย -D การลบกฎเดียวที่คุณระบุได้ดีกว่าการล้างเชน เพราะนโยบายของคุณเองยังคงอยู่

sudo iptables -D OUTPUT -p udp -j REJECT

ถ้า drop อยู่ในเชนที่ผู้ใช้กำหนด ให้ลบการกระโดดไปยังเชนนั้นก่อน แล้วลบเชนด้วย -X ทีหลัง การตั้งนโยบายเชนเป็น ACCEPT ขณะกฎ drop ยังอยู่ช่วยได้เฉพาะแพ็กเก็ตที่ไปถึงการตัดสินนโยบายเท่านั้น การล้างทุกตารางเป็นทางสุดท้าย: มันลบกฎที่คุณเพิ่มด้วยเหตุอื่นด้วย และเมื่อเปิด ufw มันทำให้บริการเข้าใจว่าตนเป็นเจ้าของเชนที่ไม่มีอยู่แล้ว

หาผู้เป็นเจ้าของที่ใส่กลับ

หลังการซ่อมทันที ให้มองหาสิ่งที่จะกู้คืนสถานะ บน Linux ตรวจว่ายูนิตคงทนเปิดอยู่หรือไม่ ไคลเอนต์มีการตั้งค่ากู้คืนไฟร์วอลล์ตอนล็อกอินหรือไม่ และมีไฟล์กฎที่บันทึกไว้ใต้ /etc หรือไม่ บน Windows ตรวจรายการเริ่มต้น บริการ และงานที่ตั้งเวลาไว้อีกครั้ง แล้วรีบูตและอ่านสถานะด้วยคำสั่งเดิมเหมือนก่อนหน้า

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

ตรวจสอบด้วยทราฟฟิกจริง ไม่ใช่ ping ครั้งเดียว

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

เก็บหลักฐานไว้: คีย์ BFE ที่ส่งออก หรือผลลัพธ์ iptables -S ที่จับไว้ก่อนการเปลี่ยนแปลง ก่อนจะบอกว่าแก้แล้ว ให้ยืนยันชั้นที่คุณลบวัตถุออก ผู้เป็นเจ้าของที่อาจติดตั้งมันใหม่ สถานะหลังบูตสะอาดหนึ่งครั้ง และการท่องเว็บปกติทำงานได้โดยไม่มีโปรเซส VPN หน้าแมนนวลของ iptables(8) มีไวยากรณ์การลบและนโยบายที่แน่นอนหากคุณเขียนสคริปต์ทำความสะอาด