คำเตือน AF_INET ของ OpenVPN: การถอยกลับที่ไม่เป็นอันตรายหรือซ็อกเก็ตที่ล้มเหลว?

บันทึกสองบรรทัดของ OpenVPN ขึ้นต้นด้วยคำเดียวกัน และมีเพียงบรรทัดเดียวที่รายงานปัญหา Could not determine IPv4/IPv6 protocol. Using AF_INET เป็นการแจ้งเตือนการถอยกลับ: โปรไฟล์ปล่อยตระกูลแอดเดรสไว้เปิด ดังนั้นดีมอนจึงเลือกหนึ่งอย่างและดำเนินการต่อ สาขาความล้มเหลวรายงานว่าไม่ได้สร้างซ็อกเก็ตและขอให้รีสตาร์ท ทุกอย่างหลังคำนำร่วมแยกทั้งสองออกจากกัน ดังนั้นอ่านต่อไปก่อนที่คุณจะเปลี่ยนอะไร

การแจ้งเตือนการถอยกลับรายงานอะไร

OpenVPN ยอมรับตระกูลที่ระบุชัดเจนผ่าน proto udp4 หรือ proto udp6 และยอมรับ proto udp เมื่อต้องอนุมานตระกูลตอนเริ่มระบบ ในกรณีที่สองดีมอนจะตรวจสอบข้อมูลการผูกในเครื่องและเลือก

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

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

สาขาความล้มเหลวมีลักษณะอย่างไร

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

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

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

ตรวจสอบตัวรับฟังแทนคำเตือน

เซิร์ฟเวอร์ที่ทำงานอยู่ตอบคำถามเรื่องตระกูลโดยตรง โดยไม่ต้องอนุมานจากข้อความบันทึก

ss -lunp | grep openvpn
ss -ltnp | grep openvpn

จับคู่ตระกูล แอดเดรส และพอร์ตกับโปรไฟล์ บรรทัด 0.0.0.0:1194 เป็น IPv4 เท่านั้น ขณะที่บรรทัด [::]:1194 บนโฮสต์แบบสองสแตกอาจยอมรับทั้งสองตระกูลขึ้นอยู่กับการตั้งค่า bindv6only หากโปรไฟล์ระบุ udp และซ็อกเก็ตเป็น IPv4 ไคลเอนต์ที่ตัวแปลงชื่อคืนเฉพาะระเบียน AAAA จะ ล้มเหลวก่อนที่อุโมงค์จะถูกเจรจาเสียอีก

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

เมื่อใดการบังคับตระกูลจึงถูกต้อง

การปักหมุด proto udp4 เหมาะกับการใช้งาน IPv4 เท่านั้น: ชื่อ DNS แบบ A เท่านั้น กฎไฟร์วอลล์สำหรับแอดเดรส v4 หนึ่งรายการ ไคลเอนต์ที่อยู่หลังผู้ให้บริการที่ให้เฉพาะแอดเดรส v4 ช่วยขจัดความกำกวมและทำให้ชุดบรรทัดบันทึกถัดไปคาดเดาได้

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

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

เก็บบันทึกให้แคบ

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

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

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