ufw allow 443 ไม่ได้ช่วยอะไรกับบริการที่อยู่หลัง VPN

Ping สำเร็จจากไคลเอนต์ VPN แต่บริการ TCP หมดเวลา และ ufw allow 443/tcp ไม่ได้เปลี่ยนอะไรเลย เมื่อแอปพลิเคชันทำงานบนโฮสต์ที่อยู่หลังเกตเวย์ ไม่ใช่บนเกตเวย์เอง การอนุญาตนั้นจึงถูกเขียนไว้สำหรับเส้นทางจราจรที่ผิด แพ็กเก็ตไม่ได้ถูกระบุถึงไฟร์วอลล์และไม่ได้ถูกส่งถึงโปรเซสภายในเครื่อง กฎขาเข้าจึงไม่เคยเห็นมันเลย การแก้ไขคือกฎเส้นทางที่เล็งไปที่โฟลว์ที่ถูกส่งต่อ และหลักฐานนั้นอยู่ในบันทึกแล้ว

ตัดสินว่าปลายทางอยู่ในเครื่องหรือถูกส่งต่อ

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

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

อ่านบล็อกก่อนเพิ่มกฎใด ๆ

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

sudo dmesg | grep "UFW BLOCK" | tail -n 5
sudo ufw status numbered

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

เขียนกฎเส้นทางที่แคบที่สุดที่เหมาะสม

ในตัวอย่างนี้ไคลเอนต์มาถึง tun0 จาก 172.20.8.0/24 บริการรับฟังที่ 10.30.0.15 บนพอร์ต 8443 และเกตเวย์ออกผ่าน ens5 ค่าเหล่านั้นถูกเลือกให้ไม่คล้ายกับค่าเริ่มต้นของ VPC บนคลาวด์ 10.0.0.0/16 หรือเครือข่ายที่บ้าน 192.168.0.0/16 เลย และ 8443 ทำให้ตัวอย่างห่างจากตัวรับฟัง 443 ของเกตเวย์เอง

sudo ufw --dry-run route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443

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

รักษาเส้นทางขากลับให้มีสถานะ

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

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

sudo ufw route allow in on tun0 out on ens5 proto tcp from 172.20.8.0/24 to 10.30.0.15 port 8443
sudo ufw status numbered

ตรวจสอบสิ่งที่ UFW บังคับใช้แทนคุณไม่ได้

กฎที่ถูกต้องยังต้องมีการส่งต่อในเคอร์เนลและเส้นทางที่ไปถึงบริการ ยืนยันทั้งสองอย่างก่อนกล่าวโทษไฟร์วอลล์เป็นครั้งที่สอง

sysctl net.ipv4.ip_forward
ip route get 10.30.0.15

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

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