สวิตช์ตัดการเชื่อมต่อของ UFW บล็อก VPN ของคุณอยู่หรือเปล่า? อนุญาตเพียร์

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

ทำไมการอนุญาตบน tun0 จึงไม่ตรงกับอะไรเลยในตอนแรก

ไคลเอนต์สร้าง tun0 หลังจากมีเซสชันแล้ว เดตลาแกรมที่สร้างเซสชันนั้นเป็นแพ็กเก็ต UDP ธรรมดาที่ส่งถึงผู้ให้บริการที่พอร์ต 1194 และออกผ่าน wlan0 หรือ eth0 พร้อมที่อยู่ต้นทางทางกายภาพ allow out on tun0 ตรงกับเฉพาะทราฟฟิกที่มีอินเทอร์เฟซขาออกเป็น tun0 เท่านั้น ในระหว่างแฮนด์เชกจึงไม่ตรงกับอะไรเลย

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

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

สองชุดแพ็กเก็ตต้องการอะไร

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

sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow out to 203.0.113.10 port 443 proto tcp comment 'tcp fallback'

แทนที่ที่อยู่และพอร์ตด้วยค่าจากโปรไฟล์ของคุณเอง เพียร์ WireGuard มักตอบบน 51820/udp ส่วนโปรไฟล์ OpenVPN ที่วิ่งผ่าน TCP 443 ต้องใช้พอร์ตนั้นแทน รายละเอียดต่างกัน แต่รูปแบบไม่ต่าง กฎทั้งสองแคบ และเมื่อรวมกันแล้วพวกมันกำหนดปลายทางเดียวที่เครื่องเข้าถึงได้ขณะที่อุโมงค์ล่ม

ลำดับคือตำนานที่สอง ด้วย iptables ดิบคุณอ่านเชนจากบนลงล่างและให้เหตุผลว่ากฎใดชนะ ufw ไม่ใช่เปลือกบาง ๆ รอบรายการที่คุณพิมพ์ มันคอมไพล์กฎของคุณเข้าเชนของตัวเองและเลือกจุดแทรก ufw status พิมพ์กฎเหล่านั้นตามลำดับของ ufw ไม่ใช่ของคุณ เมื่อกฎดูเหมือนถูกละเลย ให้เปรียบเทียบ ufw show added กับชุดที่คอมไพล์แล้วจาก iptables -S | grep ufw ก่อนเขียนอะไรใหม่

ข้อยกเว้นต้องกว้างเพียงหนึ่งที่อยู่

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

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

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

สร้างนโยบายก่อนที่อุโมงค์จะถูกต้องการ

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

sudo ufw default deny incoming
sudo ufw default deny outgoing
sudo ufw allow out on tun0
sudo ufw allow out to 203.0.113.10 port 1194 proto udp
sudo ufw allow 22/tcp
sudo ufw enable
sudo ufw status verbose

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

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

ทดสอบสถานะที่ถูกบล็อก และเก็บวิธีย้อนกลับ

สวิตช์ตัดการเชื่อมต่อที่ไม่ได้ทดสอบคือการเดา ตัดการเชื่อมต่อไคลเอนต์โดยตั้งใจแล้วลองโหลดหน้า มันต้องล้มเหลว เชื่อมต่อใหม่แล้วมันต้องฟื้นตัวโดยไม่แตะกฎ sudo ufw status verbose ยืนยันค่าเริ่มต้นและสถานะการบันทึก และ ufw status numbered แสดงว่ากฎทดสอบใดควรลบเมื่อมันอยู่เกินประโยชน์

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

sudo ufw reset
sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw enable

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