Transmission บน Linux: บังคับเส้นทางออกตามเจ้าของโปรเซส

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

ระบุชื่อโปรเซสที่เป็นเจ้าของการถ่ายโอน

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

systemctl status transmission-daemon
ps -o user=,pid=,cmd= -C transmission-daemon

หากยังไม่มีบัญชี ให้สร้างขึ้นเพื่อการนี้และอย่าให้มันไปรันสิ่งอื่น เขียนบัญชีและ UID ไว้ในคอมเมนต์ของกฎ เพราะกฎที่ไม่มีหัวเรื่องคือกฎที่ไม่มีใครแก้ไขได้อย่างปลอดภัย

แยกฟิลด์การรับฟังออกจากเส้นทาง

Transmission 4.x เอกสารที่อยู่รับฟังของเพียร์แยกจาก rpc-bind-address และความต่างนี้สำคัญ การตั้งค่า RPC ควบคุมเฉพาะตัวรับฟังการควบคุมระยะไกล การเปลี่ยนจึงไม่ได้เลือกเส้นทางให้ทราฟฟิกของเพียร์ การอ่านสองการตั้งค่านี้เป็นอันเดียวคือสาเหตุที่พบบ่อยที่สุดที่การตั้งค่าดูรอบคอบยังคงรั่ว เอกสารเดียวกันอธิบายทางถอยเมื่อที่อยู่รับฟังของเพียร์ไม่ถูกต้อง กล่าวคือที่อยู่ที่ใช้ไม่ได้เป็นกรณีถอยที่บันทึกไว้ ไม่ใช่การปฏิเสธที่รับประกัน

grep -E '"(peer-port|rpc-bind-address|bind-address-ipv4)"' /var/lib/transmission-daemon/.config/transmission-daemon/settings.json

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

เขียนการจับคู่เจ้าของในเชนที่ถูกต้อง

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

iptables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
iptables -A OUTPUT -m owner --uid-owner transmission -j REJECT
ip6tables -A OUTPUT -m owner --uid-owner transmission -o tun0 -j ACCEPT
ip6tables -A OUTPUT -m owner --uid-owner transmission -j REJECT

ลำดับสำคัญพอ ๆ กับการจับคู่ การอนุญาตกว้าง ๆ ที่อยู่ต้นเชนทำให้การปฏิเสธที่แม่นยำตอนท้ายไร้ผล จึงควรทบทวนทั้งเชนแทนการเพิ่มกฎแล้วหวัง รวมทั้งสองตระกูลที่อยู่หากโฮสต์รัน IPv6 เพราะนโยบายที่มีแต่ v4 เปิดทางที่ไม่มีใครเฝ้าดูไว้ คงกฎให้ติดตั้งอยู่แม้ระหว่างรีสตาร์ตของทั้งไคลเอนต์และอุโมงค์

ตัดสินว่าจะเกิดอะไรขึ้นเมื่อ tun0 หายไป

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

ip link show tun0
iptables -S OUTPUT

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

ครอบคลุมเส้นทางที่กฎมองไม่เห็น

การแปลชื่ออาจทำโดยโปรเซสตัวแปลแยกต่างหาก และเนมสเปซหรือเกตเวย์เฉพาะทางก็ให้เส้นแบ่งอีกชั้นได้หากเส้นทางแชร์และบูตสแตรปถูกออกแบบไว้เพื่อสิ่งนั้น ตัดสินว่าองค์ประกอบใดเป็นเจ้าของ DNS และมันทำตามกฎขาออกเดียวกันหรือไม่ จากนั้นดู RPC หากใช้ rpc-whitelist เครือข่ายบริหารที่อนุมัติแล้วก็เป็นส่วนหนึ่งของสัญญา แต่ช่วง RFC1918 กว้าง ๆ ไม่ใช่

ss -tunp | grep -i transmission

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

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