โฮสต์ iptables ที่ใช้เฉพาะ VPN: ตั้งชื่ออุปกรณ์ tun ไม่ใช่ tun+

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

ขั้นที่ 1: บันทึกกฎที่มีอยู่ตอนนี้

ก่อนเปลี่ยนนโยบายเริ่มต้น ให้บันทึกสถานะปัจจุบันไว้เพื่อให้การย้อนกลับเป็นคำสั่งไม่ใช่ความจำ iptables-save > /root/iptables.pre เขียนทุกตารางลงไฟล์ที่คุณกู้คืนได้ และเทอร์มินัลที่สองที่มีเซสชัน root เปิดอยู่ไม่ใช่ความวิตกเกินเหตุ เมื่อนโยบายที่คุณกำลังจะตั้งตัดการเชื่อมต่อที่หอบนโยบายนั้นอยู่ หากคุณทำงานระยะไกล ให้ตั้ง flush เป็นสวิตช์ฉุกเฉินไว้ด้วย

จากนั้นลิสต์อินเทอร์เฟซ เพราะชื่อที่คุณเดาไว้คือชื่อที่คุณควรอ่าน ip -br link แสดงว่าอะไรมีอยู่ตอนนี้ และอุโมงค์จะยังไม่ปรากฏจนกว่าจะขึ้นมา จดชื่ออุปกรณ์ไว้ขณะที่อ่าน

ขั้นที่ 2: ให้อุโมงค์มีชื่อของตัวเอง

OpenVPN รับ dev tun_work ในการกำหนดค่าฝั่งไคลเอนต์ แล้ว Linux จะสร้างอินเทอร์เฟซชื่อนั้นพอดีแทนการจัดสรร tun0 ชื่อจะคงที่ข้ามการเชื่อมต่อใหม่ตราบใดที่ไม่มีสิ่งอื่นอ้างสิทธิ์ และนั่นคือสิ่งที่ทำให้กฎที่ระบุชื่ออุปกรณ์มีความหมาย

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

ขั้นที่ 3: เขียนนโยบายโดยวางข้อยกเว้นของ endpoint ไว้ก่อน

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

# allow the tunnel to be built, then everything the tunnel carries
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A INPUT  -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT
iptables -A OUTPUT -d 198.51.100.7 -p udp --dport 1194 -j ACCEPT
iptables -A OUTPUT -o tun_work -j ACCEPT
iptables -A INPUT  -i tun_work -j ACCEPT
iptables -A INPUT  -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

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

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

ขั้นที่ 4: ตรวจลำดับ ไม่ใช่แค่การมีอยู่

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

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

ขั้นที่ 5: ทำให้อยู่รอดทั้งการบูตและตระกูลที่อยู่

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

จากนั้นตรวจ IPv6 แยกต่างหาก เพราะนโยบายปฏิเสธโดยค่าเริ่มต้นที่ดีสำหรับ IPv4 ไม่ได้บอกอะไรเกี่ยวกับอีกตระกูลหนึ่ง ip -6 route จะบอกคุณว่าโฮสต์มีเส้นทางที่พาทราฟฟิกอ้อมอุโมงค์ซึ่งจัดการเฉพาะ IPv4 ได้หรือไม่ และ ip6tables หรือ nftables ต้องมีกฎเทียบเท่าของตัวเอง ทดสอบด้วยปลายทาง IPv6-only แทนการไว้วางใจความสมมาตรของชุดกฎ

ขั้นที่ 6: ตรวจสอบและพร้อมกู้คืน

ยกอุโมงค์ขึ้น ยืนยันว่าบริการที่ตั้งใจไว้ทำงาน แล้วลองสิ่งที่นโยบายควรปฏิเสธ กู้คืนด้วย iptables-restore < /root/iptables.pre หากคำตอบทำให้คุณประหลาดใจ และเริ่มแก้กฎหลังจากนั้นเท่านั้น ความคงทนบวกเส้นทางกู้คืนที่ทดสอบแล้วคือสิ่งที่ทำให้สิ่งนี้เป็นการเปลี่ยนแปลงที่คุณทำได้สองครั้ง