dnsmasq ผูกพอร์ต 53 ไม่ได้: หาซ็อกเก็ตที่ครอบครองพอร์ตนั้น

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

ห้าขั้นตอนตามลำดับนี้: ทำซ้ำข้อผิดพลาด แสดงรายการผู้ฟัง เข้าใจ wildcard มอบหมายงาน แล้วตรวจสอบ

ขั้นที่ 1: ทำซ้ำและอ่านข้อผิดพลาด

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

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

ขั้นที่ 2: แสดงรายการเจ้าของ

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

ss -lntup 'sport = :53'

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

ขั้นที่ 3: กับดัก wildcard

ตัวเลือก bind-interfaces เปลี่ยนว่า dnsmasq ผูกซ็อกเก็ต wildcard หรือหนึ่งซ็อกเก็ตต่ออินเทอร์เฟซที่กำหนดค่าไว้ ตามที่ เอกสารอ้างอิง dnsmasq อธิบาย หากไม่มี dnsmasq อาจผูก wildcard แล้วกรองคำขอตามอินเทอร์เฟซแทน ซึ่งล้มเหลวทันทีเมื่อแดมอนอื่นครอบครอง wildcard อยู่ Linux เพิ่ม bind-dynamic ซึ่งจัดการอินเทอร์เฟซที่สร้างขึ้นหลังเริ่มทำงาน เป็นเรื่องจริงจังเมื่ออินเทอร์เฟซ VPN ปรากฏเฉพาะตอนเชื่อมต่อ

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

ขั้นที่ 4: มอบหมายงาน

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

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

ขั้นที่ 5: ตรวจสอบซ็อกเก็ต แล้วจึงตรวจเส้นทาง

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

ผลลัพธ์สามอย่างที่ต้องแยกจากกัน: ซ็อกเก็ตมีอยู่ ไคลเอนต์เข้าถึงได้ คำตอบถูกต้อง

สิ่งที่ไม่ควรทำ

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

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