OpenVPN เชื่อมต่อแต่ไม่มีอะไรไหล: หาชั้นที่แพ็กเก็ตตก

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

ซ็อกเก็ตนั้นผูกไว้หรือไม่ผูก

บริการที่รายงานว่าทำงานอยู่อาจยังผูกกับที่อยู่หรือการรับส่งที่คุณไม่ได้ตั้งใจ ถามซ็อกเก็ตเอง: ss -lunp แสดงรายการผู้รับฟัง UDP และ ss -ltnp แสดง TCP และคอลัมน์ที่คุ้มค่าอ่านคือที่อยู่ภายใน ไม่ใช่สถานะ

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

ss -lunp | grep 1194
ss -ltnp | grep 1194

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

ดักจับแพ็กเก็ตนอก ไม่ใช่ทันเนล

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

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

ตัวนับก่อน การติดตามเฉพาะเมื่อมันโกหก

เริ่มจากตัวนับ เพราะไม่เสียค่าใช้จ่าย nft list ruleset หรือ iptables -L -n -v ตอบคำถามเดียวที่สำคัญที่นี่: กฎตรงหรือไม่ ลำดับเป็นตัวกำหนดผลลัพธ์ เพราะการตรงกันครั้งแรกชนะ ด้วยเหตุนี้ DROP ที่กว้างก่อน ACCEPT ที่มาทีหลังจึงทำให้ ACCEPT นั้นตาย และด้วยเหตุนี้การเพิ่มกฎจึงแทบไม่เคยซ่อมอะไร

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

เฉพาะเมื่อตัวนับยังกำกวมเท่านั้นที่ล็อกจะคุ้มกับเสียงรบกวน และถึงอย่างนั้นก็เฉพาะส่วนแคบ ๆ: กฎ iptables ที่จำกัดอัตราและเติมคำนำหน้าบรรทัดล็อก หรือกฎ nftables ที่มี meta nftrace set 1 ขณะ nft monitor trace ทำงาน การติดตามระบุชื่อเชนและกฎที่รับหรือทิ้งแพ็กเก็ต หลังจากนั้นลบทั้งสองอย่างและเก็บการบันทึกเพย์โหลดไว้นอก

ตรวจสอบการรับส่งด้วย บริการไฟร์วอลล์ที่จำกัดเฉพาะ TCP ไม่ได้บอกอะไรเกี่ยวกับผู้รับฟัง UDP บนหมายเลขนั้น ดังนั้นกฎที่อ่านถูกต้องก็ยังทิ้งทุกแพ็กเก็ตได้

การกำหนดเส้นทางและทางกลับ

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

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

สิ่งที่บันทึกต้องบอก

สำหรับทุกการเปลี่ยนแปลง จดบันทึกระยะที่ทดสอบ หลักฐานที่อ่าน และค่าตัวนับทั้งสองข้างของมัน บันทึกนั้นเองที่ทำให้ "ตอนนี้มันทำงาน" อยู่รอดในการตรวจสอบครั้งถัดไป

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