อินสแตนซ์ OpenVPN ตัวไหนกันแน่ที่ใช้โปรไฟล์ PiVPN ของคุณอยู่จริง?

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

ตัวช่วยกับดีมอนเป็นวัตถุคนละอย่าง

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

บนโฮสต์ systemd ให้เริ่มจากยูนิตที่ทำงานอยู่ ไม่ใช่จากรายการไดเรกทอรี ชื่อขึ้นอยู่กับการแพ็กเกจ อิมเมจ Debian และ Raspberry Pi OS มักมีอินสแตนซ์เทมเพลตเช่น openvpn-server@server ส่วนการติดตั้งรุ่นเก่าใช้ openvpn@server ถามตัวจัดการว่าตัวไหนกำลังทำงาน แทนที่จะเดาจากชื่อไฟล์

systemctl list-units --type=service --all | grep -i openvpn
systemctl cat openvpn-server@server

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

ติดตามห่วงโซ่คอนฟิกที่ดีมอนแก้ไขแล้ว

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

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

systemctl show -p ExecStart --value openvpn-server@server
grep -E '^(config|dev|proto|port|local|log|log-append|status|ca|cert|key|tls-auth|tls-crypt)' /etc/openvpn/server/server.conf

ไฟล์ .ovpn ในไดเรกทอรีบ้านเป็นสิ่งประดิษฐ์ฝั่งไคลเอนต์ ดีมอนฝั่งเซิร์ฟเวอร์ไม่เคยอ่านมัน การแก้ไฟล์นั้นเพื่อซ่อมแฮนด์เชกฝั่งเซิร์ฟเวอร์จึงไม่เกิดผล

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

จับคู่ล็อกกับโปรเซส ไม่ใช่กับข้อผิดพลาดที่คุณจำได้

ปลายทางล็อกสองแบบเป็นเรื่องปกติ และมีเพียงแบบเดียวที่เป็น journal เมื่อ log-append ถูกตั้งไว้ ดีมอนจะเขียนลงไฟล์นั้น และ journal เก็บไว้น้อยนิดนอกเหนือจากบรรทัดเริ่มระบบ หากไม่มี journalctl ก็เป็นแหล่งของเหตุการณ์

journalctl -u openvpn-server@server -n 80 --no-pager

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

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

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

การสร้างอุโมงค์ใหม่ไม่ใช่ขั้นตอนการวินิจฉัย

ทางลัดที่น่าลองคือตั้งอุโมงค์ที่สองที่ง่ายกว่า: คีย์สถิต ไม่มีใบรับรอง ไม่มีการยืนยันตัวตนเพิ่มเติม มักจะเชื่อมต่อได้ และมันพิสูจน์เพียงว่าโฮสต์สองเครื่องส่ง UDP หรือ TCP ระหว่างกันได้ มันไม่ได้บอกอะไรว่าทำไมการติดตั้งที่ยืนยันด้วยใบรับรองจึงล้มเหลว และมันแทนที่แบบจำลองความปลอดภัยที่คุณถูกขอให้รักษาไว้อย่างเงียบ ๆ

เช่นเดียวกันกับการปิด tls-auth หรือ tls-crypt การผ่อน verify-x509-name หรือการทิ้งปัจจัยที่สองเพื่อให้ได้สถานะสีเขียว อุโมงค์ที่เชื่อมต่อได้เพราะถอดการตรวจสอบออกคืออีกระบบหนึ่ง ไม่ใช่ระบบที่ซ่อมแล้ว

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

สิ่งที่ควรส่งต่อให้คนถัดไป

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

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

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