UFW ทิ้งเซิร์ฟเวอร์ DNS ของ VPN ทันทีที่อุโมงค์ขึ้น
นโยบายปฏิเสธโดยค่าเริ่มต้นของ UFW ครอบคลุมอินเทอร์เฟซของอุโมงค์ด้วย เรียงทราฟฟิกตามทิศทาง อนุญาตตัวแปลงที่ถูกพุชบน tun0 แล้วเปิดเส้นทางนอก
ชื่อหยุดถูกแปลงทันทีที่ VPN เชื่อมต่อ ขณะที่ ping ไปยังที่อยู่สาธารณะยังตอบกลับ และสถานะไฟร์วอลล์ไม่แสดงอะไรที่ดูผิดปกติ ไม่มีอะไรเปลี่ยนในนโยบาย สิ่งที่เปลี่ยนคือมีอินเทอร์เฟซใหม่ปรากฏขึ้น และการปฏิเสธโดยค่าเริ่มต้นครอบคลุมมันตั้งแต่แพ็กเก็ตแรก UFW ตัดสินตามทิศทางและอินเทอร์เฟซ ดังนั้นกฎที่เขียนสำหรับลิงก์ไร้สายจึงไม่ได้พูดอะไรเกี่ยวกับทราฟฟิกที่ออกจากอุโมงค์ การซ่อมคือกฎแคบๆ ไม่กี่ข้อที่ใช้ในลำดับที่กำหนด
อาการจะปรากฏหลังอุโมงค์ขึ้นเท่านั้น
นโยบายปฏิเสธโดยค่าเริ่มต้นทำตามที่สั่งไว้เป๊ะ ทุกอย่างที่ไม่มีกฎตรงกันจะถูกปฏิเสธบนทุกอินเทอร์เฟซที่มีอยู่ อุโมงค์ยังไม่มีอยู่ตอนที่เขียนกฎ ดังนั้นไม่มีกฎใดจับมันได้ และการปฏิเสธที่มีอยู่ตลอดมาบัดนี้ใช้กับการแปลงชื่อ ทราฟฟิกตรงไปยังที่อยู่แบบตัวอักษรอาจยังทำงานได้เมื่อมีสิทธิ์ที่กว้างกว่าครอบคลุมอยู่ จึงเป็นเหตุให้ ping ไปยังตัวแปลงสาธารณะสำเร็จ ขณะที่การค้นหาชื่อล้มเหลว ช่องว่างคือกฎสำหรับอินเทอร์เฟซที่นโยบายไม่เคยเห็น
นั่นยังอธิบายว่าทำไมความล้มเหลวจึงกลับคืนอย่างสะอาด ถอดอุโมงค์ออกแล้วชื่อก็แปลงได้อีกครั้ง เพราะคำถามกลับไปยังอินเทอร์เฟซที่มีกฎอยู่ นโยบายที่ล้มเหลวเฉพาะตอนอุโมงค์ขึ้นไม่ใช่ปัญหา DNS และการปรับตัวแปลงเองเป็นสิ่งที่เสียเวลามากที่สุดตรงนี้ อ่านรายการอินเทอร์เฟซก่อนอ่านการกำหนดค่าตัวแปลง
สามทิศทาง สามชุดกฎที่ต่างกัน
เซสชันเดียวแตะกฎในมากกว่าหนึ่งทิศทาง และอุโมงค์เพิ่มอินเทอร์เฟซที่สองให้เกือบทุกอัน การเรียงทราฟฟิกตามทิศทางและอินเทอร์เฟซก่อนทำให้ส่วนที่เหลือเป็นกลไก เพราะแต่ละแถวด้านล่างต้องการกฎของตัวเองในที่ของตัวเอง ตัวอย่างใช้ tun0 และพูล 10.8.0.0/24 ดังนั้นแทนที่ชื่อและช่วงด้วยค่าจากเอาต์พุตของไคลเอนต์เอง
| Direction | Example packet | Rule that admits it | Written on |
|---|---|---|---|
| Client to the pushed resolver | A DNS query to 10.8.0.1 | Destination port 53 over the tunnel | The client's tun0 |
| Client to the VPN server | A handshake to the server's public address | Server address and port on the physical link | The client's physical interface |
| Server to a service | SSH from the pool to port 22 | Source pool, destination port, tunnel interface | The server's tun0 |
| Anyone to the listener | The VPN listener itself | 1194/udp on the public side | The server's public interface |
สองแถวมักสับสนเพราะทั้งคู่กล่าวถึงอุโมงค์ กฎสำหรับตัวแปลงอนุญาตทราฟฟิกที่ไคลเอนต์ส่งเข้าไปในอุโมงค์ ขณะที่กฎสำหรับ SSH อนุญาตทราฟฟิกที่เซิร์ฟเวอร์ได้รับจากที่นั่น ทั้งสองอยู่คนละเครื่องและล้มเหลวแยกกัน แถวที่ถูกลืมบ่อยที่สุดคือแถวที่สอง เพราะไคลเอนต์สร้างอุโมงค์ไม่ได้เลยจนกว่าทราฟฟิกของมันไปยังที่อยู่สาธารณะของเซิร์ฟเวอร์จะได้รับอนุญาต ทำงานจากบนลงล่าง และทุกความล้มเหลวมีสาเหตุที่เป็นไปได้หนึ่งอย่าง
ตัวแปลงที่ถูกพุชต้องมีกฎของตัวเอง
อุโมงค์จะพา DNS ไปหรือไม่ขึ้นอยู่กับสิ่งที่เซิร์ฟเวอร์ส่งมา เซิร์ฟเวอร์ที่พุชอ็อปชันตัวแปลงจะติดตั้งที่อยู่ส่วนตัวในการกำหนดค่าของไคลเอนต์ และที่อยู่นั้นกำหนดเส้นทางได้ผ่านอุโมงค์เท่านั้น ถ้าเซิร์ฟเวอร์ไม่พุชอะไรเลย ไคลเอนต์จะเก็บตัวแปลงเดิมไว้ และกฎด้านล่างไม่มีอะไรให้อนุญาต ตรวจสอบสถานะที่ถูกพุชและผลลัพธ์คำถามปัจจุบันก่อนเขียนอะไรลงไป:
dig +short @10.8.0.1 example.com
resolvectl status tun0
sudo ufw status numberedเอาต์พุตสถานะระบุตัวแปลงที่ใช้และลิงก์ที่ผูกอยู่ และการค้นหาเส้นทางเบื้องหลังแสดงว่าอินเทอร์เฟซใดจะพาคำถามไปยังที่อยู่นั้น เมื่อตัวแปลงอยู่บนลิงก์อื่น ปัญหาอยู่ก่อนไฟร์วอลล์และไม่มีกฎใดช่วยได้ เมื่อทั้งสองเห็นตรงกันเรื่องอุโมงค์ ต้องใช้สองกฎ เพราะ UDP พาคำถามส่วนใหญ่และ TCP เข้ามารับช่วงเมื่อคำตอบถูกตัด บันทึกทั้งสองค่า เพราะกฎจะอ้างถึงค่าเหล่านั้น:
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto udp comment 'pushed resolver'
sudo ufw allow out on tun0 to 10.8.0.1 port 53 proto tcp comment 'truncated answers'เปิดเส้นทางนอกก่อนเส้นทางใน
ไคลเอนต์ต้องไปถึงที่อยู่สาธารณะของเซิร์ฟเวอร์ก่อนที่อุโมงค์จะมีอยู่ ดังนั้นกฎสำหรับเรื่องนี้อยู่บนลิงก์กายภาพและต้องอยู่ที่ของมันก่อน นโยบายที่อนุญาตตัวแปลงแต่ลืมเซิร์ฟเวอร์ทำให้ไคลเอนต์สร้างอุโมงค์ไม่ได้เลย และอาการนั้นมักถูกโยนให้ kill switch จากนั้นอนุญาตบริการที่คุณต้องการจริงๆ ผ่านอุโมงค์ ทีละกฎแคบๆ แทนที่จะเปิดอินเทอร์เฟซทั้งหมด กฎแคบๆ คือเหตุผลที่การปฏิเสธยังคงอยู่ที่เดิมได้
sudo ufw allow out to 198.51.100.10 port 1194 proto udp comment 'vpn server'
sudo ufw allow out on tun0 to any port 443 proto tcp comment 'web through tunnel'ลำดับสำคัญระหว่างทดสอบ เพราะกฎแรกคือสิ่งที่ทำให้อุโมงค์ขึ้นได้ เพิ่มมัน เชื่อมต่อ และยืนยันว่าอุโมงค์ขึ้นก่อนเพิ่มกฎบริการ เพราะการทำทั้งสองพร้อมกันหมายความว่าความล้มเหลวไม่ได้บอกอะไรว่าครึ่งไหนผิด แทนที่ที่อยู่เอกสารด้านบนด้วยปลายทางที่ไคลเอนต์กำหนดค่าไว้
จบฝั่งไคลเอนต์ด้วยการตัดการเชื่อมต่อโดยเจตนา การปฏิเสธควรยังคงปฏิเสธทราฟฟิกที่คุณตั้งใจกันออก เพราะตัวแปลงที่ตอบขณะอุโมงค์ขึ้นครอบคลุมเพียงครึ่งเดียวของนโยบายที่ปฏิเสธเมื่อสงสัย
ไคลเอนต์ที่เชื่อมต่อยังไม่ได้รับอนุญาต
เซิร์ฟเวอร์มีทิศทางของตัวเองที่ต้องพิจารณา และไคลเอนต์ที่จบแฮนด์เชกยังไปไม่ถึงอะไรที่รันบนเซิร์ฟเวอร์จนกว่าเซิร์ฟเวอร์จะรับมัน กฎของตัวฟังสาธารณะเพียงอนุญาตให้อุโมงค์มีอยู่ ไม่ได้ให้ทราฟฟิกของอุโมงค์เข้ามา บนเซิร์ฟเวอร์นั่นคือสองกฎบวกกับการตรวจสอบหนึ่งครั้งว่าบริการกำลังฟังอยู่จริง:
sudo ufw allow 1194/udp comment 'openvpn listener'
sudo ufw limit in on tun0 from 10.8.0.0/24 to any port 22 proto tcp comment 'admin over tunnel'
ss -ltn | grep ':22'พูลในกฎต้องเท่ากับช่วงที่เซิร์ฟเวอร์จัดสรร และหมายเลขอุโมงค์ต้องตรงกับที่เซิร์ฟเวอร์สร้าง เพราะกฎสำหรับอินเทอร์เฟซอื่นแยกจากไม่มีกฎไม่ได้ limit ตั้งใจใช้กับพอร์ตบริหาร เพราะจำกัดการเชื่อมต่อซ้ำแทนที่จะรับอย่างไร้ขีดจำกัด การตรวจตัวฟังแยกพอร์ตที่ปิดออกจากแพ็กเก็ตที่ถูกทิ้ง ซึ่งมองจากไคลเอนต์แล้วเหมือนกัน กฎที่มีหมายเลขก็ไม่ใช่ภาพทั้งหมดเช่นกัน กฎ before ของ UFW และบรรทัด nftables ที่เขียนด้วยมือใดๆ จับคู่ก่อนและยังปฏิเสธแพ็กเก็ตที่รายการดูเหมือนอนุญาตได้