เผยแพร่พอร์ตไคลเอนต์ VPN จากเบื้องหลัง CGNAT: รายการตรวจสอบ

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

ยืนยันว่าเซิร์ฟเวอร์จะส่งต่อเลยหรือไม่

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

sysctl net.ipv4.ip_forward
sysctl -w net.ipv4.ip_forward=1

การตั้งค่าในเคอร์เนลที่กำลังทำงานไม่เหมือนกับการตั้งค่าให้อยู่รอดข้ามการรีบูต เขียน net.ipv4.ip_forward=1 ลงในไฟล์ใต้ /etc/sysctl.d/ รัน sysctl --system แล้วอ่านค่ากลับแทนที่จะเชื่อว่าไฟล์นั้นถูกอ่านแล้ว คอนเทนเนอร์ที่จัดการเนมสเปซเครือข่ายของตัวเองก็ต้องการค่าเดียวกันภายในเนมสเปซนั้น ไม่ใช่แค่บนโฮสต์

ถ้าอ่านกลับแล้วยังเป็นศูนย์ ให้หยุดตรงนี้ ไม่มีอะไรหลังจากนี้จะทำงานได้

ปักหมุดที่อยู่ของอุโมงค์ก่อนที่กฎใดจะอ้างถึงมัน

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

client-config-dir /etc/openvpn/ccd
ifconfig-push 10.77.0.14 10.77.0.13

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

ถ้าที่อยู่เปลี่ยนหลังเชื่อมต่อใหม่ ให้หยุด กฎ NAT ที่ตามเป้าหมายที่เคลื่อนไหวจะล้มเหลวเป็นระยะและไม่สอนอะไรคุณเลย

แปลทั้งสองทิศทาง

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

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 29443 -j DNAT --to-destination 10.77.0.14:29443
iptables -t nat -A POSTROUTING -d 10.77.0.14 -p tcp --dport 29443 -j SNAT --to-source 10.77.0.13

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

อ่านกฎทั้งสองกลับด้วย iptables -t nat -S และยืนยันว่าชื่ออินเทอร์เฟซคือตัวที่พาที่อยู่สาธารณะ บนโฮสต์ที่กรองด้วย nftables อยู่แล้ว ให้เขียนการแปลในเชน NAT ของ nftables ตระกูลที่อยู่ที่ตรงกัน แทนที่จะผสมเครื่องมือ

ปล่อยให้ตารางตัวกรองผ่านไป

ตาราง NAT เขียนหัวแพ็กเก็ตใหม่ ไม่ได้ให้สิทธิ์ ด้วยนโยบาย DROP เริ่มต้น โฟลว์ที่ถูกส่งต่อต้องมีกฎยอมรับของตัวเอง บวกทิศทางขากลับที่นโยบายส่วนใหญ่ครอบด้วยกฎ established,related อยู่แล้ว

iptables -A FORWARD -i eth0 -o tun0 -p tcp --dport 29443 -m conntrack --ctstate NEW -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

ตรวจสอบนโยบายของเชน FORWARD ก่อนเพิ่มอะไร เพราะลำดับของ DROP ที่อยู่ต้นทางเป็นตัวตัดสินว่ากฎของคุณจะถูกพิจารณาหรือไม่ บนโฮสต์ที่การกรองอยู่ใน nftables ให้เพิ่มกฎที่เทียบเท่าไปยังฮุก forward ของตาราง inet และยืนยันว่าเชนฐานมองเห็นทราฟฟิกที่ถูกส่งต่อจริง ไม่ใช่เพียงอินพุตภายในเครื่อง หากตัวนับแพ็กเก็ตบนกฎใหม่ยังเป็นศูนย์ขณะที่ตัวนับ NAT เพิ่มขึ้น แพ็กเก็ตกำลังถูกทิ้งก่อนถึงกฎของคุณ นั่นคือสัญญาณให้อ่านลำดับเชน ไม่ใช่ให้เพิ่มสำเนาที่สองของกฎเดิม

พิสูจน์จากเครือข่ายภายนอก

ทดสอบจากเครือข่ายที่ไม่เกี่ยวข้อง การตรวจจากเครื่องอื่นใน LAN เดียวกันอาจผ่านการรองรับ hairpin NAT และไม่เคยใช้เส้นทางที่ไคลเอนต์ระยะไกลใช้ ผลลัพธ์สีเขียวตรงนั้นจึงพิสูจน์สิ่งที่ผิด

tcpdump -ni any port 29443
conntrack -L | grep 29443

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

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