เซิร์ฟเวอร์หรือไคลเอนต์: ยูนิต OpenVPN ตัวไหนบน Pi ที่มีสองบทบาท

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

จับคู่ชื่อยูนิตกับไดเรกทอรีที่มันโหลด

Upstream 2.6 มียูนิตเทมเพลตสองตัว คือ [email protected] และ [email protected] เทมเพลตเซิร์ฟเวอร์เริ่มทำงานใน /etc/openvpn/server และโหลด %i.conf จากที่นั่น เทมเพลตไคลเอนต์เริ่มทำงานใน /etc/openvpn/client อินสแตนซ์ชื่อ roaming สามารถมีอยู่ได้ทั้งสองที่พร้อมกัน ทั้งในฐานะเซิร์ฟเวอร์และไคลเอนต์ ด้วยการกำหนดค่าสองชุดที่ไม่เกี่ยวข้องกัน และไม่มีความเชื่อมโยงระหว่างกันนอกจากสตริง

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

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

ตัดสินด้วยทิศทางของแพ็กเก็ต ไม่ใช่ชื่ออินเทอร์เฟซ

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

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

ดูซ็อกเก็ตก่อนจะตั้งทฤษฎี เซิร์ฟเวอร์ที่ผูกกับ udp/1194 แสดงซ็อกเก็ตรอฟัง ไคลเอนต์แสดงความเชื่อมโยงกับที่อยู่ของผู้ให้บริการและไม่มีอะไรที่รอฟังเลย

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

เส้นทางเริ่มต้นของอินสแตนซ์หนึ่งอาจดักจับคำตอบของอีกตัวหนึ่ง

redirect-gateway ที่ไคลเอนต์ต้นทางดันเข้ามาจะติดตั้งเส้นทางเริ่มต้นที่แข่งขันกับทุกสิ่งอื่นบนเครื่อง รวมถึงคำตอบที่เซิร์ฟเวอร์ส่งให้ผู้ใช้ที่ roaming OpenVPN ตั้งข้อยกเว้นสำหรับที่อยู่เพียร์ของตัวเองเพื่อให้อุโมงค์ยังเข้าถึงได้ แต่ข้อยกเว้นนั้นไม่ได้บอกอะไรเกี่ยวกับโทรศัพท์ที่อยู่ในเครือข่ายโรงแรม

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

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

ip route get 203.0.113.44
ip rule show

รีสตาร์ตบทบาทหนึ่งและพิสูจน์ว่าอีกบทบาทยังอยู่

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

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

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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