พอร์ต 1194 ถูกใช้งานแล้ว: ใครเป็นเจ้าของซ็อกเก็ต OpenVPN นี้?

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

ข้อผิดพลาดนี้อธิบายการไบน์ดิ้งภายในเครื่องและไม่มีอะไรเกินกว่านั้น ไม่ใช่หลักฐานว่าผู้ให้บริการบล็อกพอร์ต ลูกค้าส่งรหัสผ่านผิด หรือห่วงโซ่ใบรับรองเสีย

อ่านข้อผิดพลาดการไบน์ดิ้งที่แน่นอน

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

systemctl status openvpn-server@lab --no-pager
journalctl -u openvpn-server@lab -n 20 --no-pager

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

ทำบัญชีซ็อกเก็ต ไม่ใช่พอร์ต

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

ss -lunp | grep -F ':1194'
ss -ltnp | grep -F ':1194'
ss -lunp 'sport = :1194'

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

ค้นหาว่าโปรเซสใดเป็นเจ้าของ

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

sudo ss -lunp 'sport = :1194'
sudo fuser -v -n udp 1194

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

เจ้าของหนึ่งราย หรือสองอินสแตนซ์ที่ออกแบบไว้

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

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

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

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

ตรวจสอบการไบน์ดิ้งก่อนสิ่งอื่นใด

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

ss -lunp 'sport = :1194'
systemctl is-active openvpn-server@lab
journalctl -u openvpn-server@lab -f

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