การนำเข้าใน NetworkManager ล้มเหลวกับไฟล์ OpenVPN และ WireGuard

ฉันเลือกนำเข้าจากไฟล์…ในตั้งค่า GNOME เลือกโปรไฟล์ที่ใช้ได้กับไคลเอนต์ของผู้ให้บริการ แล้วกล่องโต้ตอบก็ปิดลงโดยไม่ได้เพิ่มอะไรในรายการ บนแล็ปท็อปเครื่องที่สอง การนำเข้าสำเร็จ การเชื่อมต่อปรากฏใต้ชื่อโปรไฟล์ แล้วก็ล้มเหลวที่การขอรับรองตัวตนครั้งแรก NetworkManager ไม่เคยรันไฟล์ .ovpn หรือ wg-quick ของคุณตามที่เป็นอยู่ มันส่งไฟล์ให้ตัวแยกวิเคราะห์ ตัวแยกวิเคราะห์แปลงเป็นรูปแบบการเชื่อมต่อของ NetworkManager เอง และจากนั้นอุโมงค์ก็ถูกสร้างจากออบเจ็กต์ที่แยกวิเคราะห์แล้ว — ความลับ เส้นทาง DNS และทุกอย่าง คำถามที่มีประโยชน์จึงไม่ใช่ทำไมไฟล์ถึงเสีย แต่คือการแยกวิเคราะห์เกิดขึ้นหรือไม่และเก็บอะไรไว้

การนำเข้าทำอะไรกับไฟล์จริง ๆ

สำหรับOpenVPNตัวแยกวิเคราะห์อยู่ในแพ็กเกจปลั๊กอิน และการเชื่อมต่อที่สร้างขึ้นชี้ไปยังบริการ D-Bus เช่น org.freedesktop.NetworkManager.openvpn ถ้าไม่มีปลั๊กอินก็ไม่มีตัวแยกวิเคราะห์ nmcli ไม่รู้จักชนิดนี้ และรายการเพิ่ม VPN แบบกราฟิกอาจไม่แสดงรายการนำเข้าเลย WireGuard ต่างออกไปในจุดสำคัญจุดหนึ่ง — NetworkManager มีการตั้งค่า WireGuard ของตัวเองมาตั้งแต่ชุด 1.30 จึงไม่มีแพ็กเกจปลั๊กอินแยก แต่ตัวอ่าน wg-quick มีเฉพาะในบิลด์ที่จัดส่งมาเท่านั้น

ไม่ว่าอย่างไร ไฟล์จะถูกอ่านครั้งเดียว ผลลัพธ์เขียนเป็น keyfile ใต้ /etc/NetworkManager/system-connections/ ตั้งชื่อตามการเชื่อมต่อ เป็นของ root และผู้ใช้อื่นอ่านไม่ได้เพราะมีวัสดุกุญแจอยู่ keyfile นั้นคือการเชื่อมต่อในตอนนี้ การแก้ไฟล์ .ovpn ต้นฉบับภายหลังไม่เปลี่ยนอะไร

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

ยืนยันปลั๊กอินก่อนแก้ปัญหาโปรไฟล์

ปลั๊กอินที่หายไปดูเหมือนโปรไฟล์ที่เสียหายทุกประการดังนั้นตรวจแพ็กเกจก่อน บน Debian และ Ubuntu การสนับสนุน OpenVPN มาเป็น network-manager-openvpn พร้อมตัวช่วยเดสก์ท็อป บน Fedora แพ็กเกจคือ NetworkManager-openvpn และ NetworkManager-openvpn-gnome บน Arch คือ networkmanager-openvpn

dpkg -l network-manager-openvpn-gnome | tail -n 2
rpm -q NetworkManager-openvpn
pacman -Q networkmanager-openvpn

จากนั้นนำเข้าจากพาธแบบสัมบูรณ์: nmcli connection import type openvpn file /home/you/profile.ovpn พาธแบบสัมพัทธ์มักใช้ได้ แต่เชลล์ที่เปลี่ยนไดเรกทอรีทำให้การนำเข้าที่รวดเร็วกลายเป็นทางอ้อม สำหรับ WireGuard ตรวจ nmcli --version และตรวจว่าฝั่งเคอร์เนลมีอยู่ด้วย modprobe wireguard การนำเข้าที่สำเร็จบนเครื่องที่ไม่มีมอดูลจะทิ้งการเชื่อมต่อที่อุปกรณ์ไม่เคยปรากฏเอกสารอ้างอิง nmcliอธิบายคำสั่งย่อย import และชื่อชนิดที่ยอมรับ หาก type wireguard ถูกปฏิเสธทันที บิลด์นั้นเก่ากว่าฟีเจอร์นี้ และขั้นตอนที่ถูกต้องคือแพ็กเกจของดิสทริบิวชันหรือ backport ไม่ใช่การคัดลอกคอนฟิกไปยังไดเรกทอรีใด ๆ แล้วหวังว่าจะมีอะไรอ่านมัน

อ่านการเชื่อมต่อ OpenVPN ไม่ใช่ไฟล์ .ovpn

เมื่อการเชื่อมต่อมีอยู่ ให้อ่านการตั้งค่าที่แยกวิเคราะห์แล้วแทนการอ่านไฟล์ใหม่: nmcli connection show "Work VPN" | grep -E '^vpn\.' คุณต้องการ remote และพอร์ต ทรานสปอร์ต วัสดุระบุตัวตน — ca, cert, key, tls-auth หรือ tls-crypt — และวิธีการรับรองตัวตน ในโปรไฟล์ที่มีรหัสผ่านคีย์ส่วนตัว ให้เพิ่ม sudo nmcli --show-secrets connection show "Work VPN" แล้วดูแฟล็ก secret: 0 คือ none ความลับจึงอยู่ใน keyfile; 1 คือ agent-owned; 2 คือ not-saved หมายความว่าไม่เคยเขียนลง keyfile; 4 คือ not-required หมายความว่าไม่ต้องใช้ความลับเลย สิ่งเหล่านี้เป็นบิตไม่ใช่สเกล ดังนั้น 3 จึงเป็น agent-owned บวก not-saved ความลับที่ถามครั้งเดียวต่อเซสชันคือ agent-owned (1) โดยเอเจนต์เป็นผู้ขอ ไม่มีหมายเลขแฟล็กแยกสำหรับสิ่งนั้น แฟล็กไม่ตรงกันเป็นสาเหตุปกติที่โปรไฟล์เชื่อมต่อได้จากแอปเพล็ตเดสก์ท็อปแต่ล้มเหลวจากสคริปต์หรือตอนบูต

วิธีที่เร็วที่สุดในการดูว่าตัวแยกวิเคราะห์ทิ้งอะไรไปคือขอให้ปลั๊กอินเขียนไฟล์กลับแล้วเทียบ: nmcli connection export "Work VPN" /tmp/roundtrip.ovpn ไดเรกทีฟที่หายไปในการเทียบนั้นจะไม่มีอยู่ตอนเชื่อมต่อ ฮุกคือผู้ต้องสงสัยปกติ — script-security, up, down และ route-up คาดหวังสคริปต์ที่รันด้วยสิทธิ์สูงและถูกตัดออกโดยเจตนา อย่าลดการตรวจสอบหรือให้สิทธิ์เพิ่มเพื่อให้การนำเข้าสำเร็จ ตัวเลือกที่ไม่รองรับมักสะท้อนชุดฟีเจอร์ของปลั๊กอิน ไม่ใช่เซิร์ฟเวอร์ที่เข้าถึงไม่ได้ ย้ายพฤติกรรมนั้นไปยังสคริปต์ dispatcher ของ NetworkManager หรือนโยบายฝั่งเซิร์ฟเวอร์

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

อ่านการเชื่อมต่อ WireGuard ไม่ใช่ไฟล์ wg-quick

ไฟล์ wg-quick เป็นรูปแบบที่มีความหมายแบบเชลล์ การเชื่อมต่อที่นำเข้าเป็นชุดการตั้งค่า PrivateKey กลายเป็นคีย์ส่วนตัวของอินเทอร์เฟซ Address กลายเป็นที่อยู่ IPv4 และ IPv6 หนึ่งรายการหรือมากกว่า DNS แมปกับพร็อพเพอร์ตี resolver ของ NetworkManager MTU แมปกับ wireguard.mtu (ค่าเริ่มต้นของ wg-quick เองคือ 1420) และแต่ละบล็อก peer กลายเป็นรายการ peer ที่มีคีย์สาธารณะ endpoint IP ที่อนุญาต และ persistent keepalive พิมพ์สิ่งที่เก็บไว้ด้วย nmcli --show-secrets connection show wg0 หากรายการ peer ไม่ปรากฏในเอาต์พุตนั้น ให้อ่าน keyfile:

sudo sed -n '/^\[wireguard\]/,/^\[/p' /etc/NetworkManager/system-connections/wg0.nmconnection

สิ่งที่อยู่รอดคือครึ่งที่เป็นเชลล์ของ wg-quick PreUp, PostUp, PreDown, PostDown และ Table เป็นพฤติกรรมของเครื่องมือนั้น ไม่ใช่แอตทริบิวต์ของอินเทอร์เฟซ WireGuard ดังนั้นจึงไม่มีอะไรเรียกใช้หลังการนำเข้า หากต้นฉบับใช้ Table = off เพื่อไม่แตะเส้นทางเริ่มต้น รีลีส NetworkManager ใหม่ ๆ มี ip4-auto-default-route และ ip6-auto-default-route เพื่อจุดประสงค์เดียวกัน ตั้งค่าให้ชัดเจนแทนการสมมติว่าการเชื่อมต่อทำงานเหมือนสคริปต์ ฮุกที่ผลักเส้นทางกำหนดเองต้องมีเส้นทางนั้นในการตั้งค่าเส้นทางของอินเทอร์เฟซ มิฉะนั้นมันจะหายไปเฉย ๆ

ให้การเชื่อมต่อมีเจ้าของเพียงหนึ่งเดียว

ความล้มเหลวที่ตามมาอย่างคลาสสิกคือการเชื่อมต่อที่ใช้ได้จนถึงการบูตครั้งถัดไปแล้ววนซ้ำ โดยปกติ [email protected] ยังเปิดอยู่จากการทดลองก่อนหน้า หรือไคลเอนต์ของผู้ให้บริการเปิดเดมอนของตัวเอง และเจ้าของสองรายกำลังเขียนเส้นทางและ DNS ให้ปลายทางเดียวกัน NetworkManager ตั้ง resolver ผ่านเส้นทางของตัวเอง wg-quick เขียนผ่าน resolvconf และผู้เขียนคนสุดท้ายชนะ การแปลงชื่อจึงใช้ได้ แล้วหยุด แล้วใช้ได้อีก ตรวจ systemctl status wg-quick@wg0, nmcli connection show --active และ ip link show type wireguard แล้วปิดเจ้าของรายที่สองแทนการปรับ metric ของมัน

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

ตรวจสอบด้วยทราฟฟิกและอยู่รอดจากการรีบูต

ยกการเชื่อมต่อขึ้นด้วย nmcli connection up "Work VPN" แล้วอ่านสถานะ ที่อยู่ และเส้นทางแทนการเชื่อมป้าย: nmcli device show wg0 | grep -E 'GENERAL.STATE|IP4.ADDRESS|IP4.ROUTE', ip route show default และการค้นหาชื่อจริงที่แก้ได้เฉพาะในอุโมงค์ การจับมือหรือ ping ที่สำเร็จพิสูจน์เพียงว่าการเข้ารหัสทำงาน ไม่ได้บอกอะไรเกี่ยวกับการส่งต่อ คำนำหน้า split tunnel หรือ DNS ส่วนตัว และนั่นคือส่วนที่มักพัง

จากนั้นรีบูตและทำซ้ำ พฤติกรรม autoconnect อินเทอร์เฟซที่ถูกเปลี่ยนชื่อ และปลั๊กอินที่โหลดหลังอุปกรณ์ล้วนเป็นความล้มเหลวที่เห็นเฉพาะตอนบูตสะอาด journalctl -u NetworkManager -b --no-pager | tail -n 40 แสดงว่าเดมอนทำอะไรกับการเชื่อมต่อนี้ในการบูตครั้งนี้ สำหรับคอมพิวเตอร์เครื่องที่สอง ให้คัดลอก keyfile และเก็บเป็นของ root โหมด 600 หรือใช้ nmcli connection export สำหรับ OpenVPN แล้วนำเข้าไฟล์ .ovpn ที่ได้ใหม่ — เส้นทางการส่งออกไม่มีสิ่งที่เทียบเท่าใน WireGuard ทิศทางนั้นจึงเป็นการคัดลอกไฟล์หรือการนำเข้าใหม่จากต้นฉบับที่ป้องกันไว้

ฉบับสั้นตามลำดับ: ยืนยันปลั๊กอินหรือเวอร์ชัน NetworkManager นำเข้าจากพาธแบบสัมบูรณ์ อ่านการตั้งค่าที่แยกวิเคราะห์รวมถึงแฟล็ก secret เทียบการส่งออก OpenVPN กับต้นฉบับ ตรวจฮุกและเส้นทางฝั่ง WireGuard ปิดเจ้าของรายที่สองใด ๆ แล้วหลังรีบูตตรวจการแปลงชื่อและตารางเส้นทาง เมื่อการเชื่อมต่อผ่านทั้งหมดนั้น ไฟล์โปรไฟล์ที่เริ่มมันไว้ก็กลับไปยังที่จัดเก็บที่ป้องกันได้