VPN NAT อยู่ในส่วนใดของ before.rules ใน UFW และจะทดสอบอย่างไร

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

คำสั่งเชลล์ไม่ใช่ไฟล์กู้คืน

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

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

วางส่วนย่อยไว้ภายในส่วนตารางที่มีอยู่

ส่วนย่อย NAT มีรูปร่าง และรูปร่างสำคัญกว่าข้อความกฎภายใน หัวตารางเปิดส่วน การประกาศเชนตั้งค่าตัวนับ กฎตามมา และ COMMIT ปิดส่วน

*nat
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -s 10.55.0.0/24 -o ens3 -j MASQUERADE
COMMIT

พูลและอินเทอร์เฟซด้านบนเป็นตัวแทนสำหรับค่าของคุณ โครงสร้างคือส่วนที่ควรคัดลอก หากไฟล์มีส่วน *nat อยู่แล้ว ให้เพิ่มกฎภายในส่วนนั้นแทนการเปิดส่วนที่สอง เพราะรูปแบบคาดหวัง COMMIT หนึ่งรายการต่อตาราง และสองส่วนสำหรับตารางเดียวกันคือการซ่อมแซมที่รอเกิดขึ้น รักษานิยามเชนของดิสทริบิวชันไว้ รวมถึงสิ่งที่ผู้จำหน่ายเพิ่มสำหรับการผสานรวมของตนเอง คู่มือเฟรมเวิร์ก UFW อธิบายไฟล์ before, user และ after พร้อมข้อกำหนด COMMIT ที่ตรงกัน

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

ทดสอบตัวเลือกโดยไม่นำไปใช้

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

sudo cp /etc/ufw/before.rules /root/before.rules.bak
sudo iptables-restore --test < /root/before.rules.bak
echo "exit: 0"

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

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

แยกการส่งต่อ NAT และนโยบายการเข้าถึงออกจากกัน

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

sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo iptables -S FORWARD

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

ตรวจสอบการโหลดใหม่ การปฏิเสธ และการสูญเสีย VPN

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

sudo ufw reload
sudo ufw status verbose
sudo iptables -t nat -L POSTROUTING -n -v

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

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