วิธีอพยพเซิร์ฟเวอร์ VPN บน Raspberry Pi ไปยัง Ethernet

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

บันทึกผู้รับผิดชอบทั้งสี่ก่อนถอดอะไรก็ตาม

การตั้งค่าสี่อย่างตัดสินว่าการสลับจะรอดหรือไม่: แอดเดรสของ Pi แอดเดรสที่ผูกกับ OpenVPN เป้าหมายการเปลี่ยนเส้นทางของเราเตอร์ และเส้นทางที่คำตอบเดินทาง บันทึกทั้งสี่ก่อนแตะสายเคเบิล เพราะเมื่อ lease ไร้สายหายไปคุณจะอ่านค่าเก่าจากเครื่องไม่ได้อีก อินเทอร์เฟซแบบมีสายไม่สืบทอดโปรไฟล์ไร้สาย และบน Bookworm แอดเดรสอาศัยอยู่ใน NetworkManager ขณะที่ Bullseye เก็บไว้ใน dhcpcd.conf. การจองที่ปักหมุด MAC ไร้สายไม่ได้บอกอะไรเกี่ยวกับ eth0. มองแอดเดรสใหม่เป็นการกำหนดใหม่ที่ต้องมีหลักฐานของตัวเอง

Old wireless lease:   10.42.7.24/24 on wlan0
New wired address:    10.42.7.31/24 on eth0
Client endpoint:      vpn.lab.example:1194/udp

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

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

อ่านซ็อกเก็ตจริงก่อนเชื่อแอดเดรสใหม่

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

sudo systemctl cat openvpn-server@server | grep -n -- '--local'
sudo ss -lunp '( sport = :1194 )'

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

เดินการย้ายตามลำดับที่ทำให้คุณเข้าถึงได้

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

ip -br addr show eth0
ip route get 203.0.113.10
nmcli -g ipv4.method,ipv4.addresses con show "Wired connection 1"

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

เมื่อลิงก์ทั้งสองทำงาน Pi อาจเลือกเส้นทางเริ่มต้นแบบไร้สายเพราะติดตั้งก่อน หรือเพราะลิงก์แบบมีสายมีเมตริกสูงกว่า บน Bookworm ตัวปรับที่รองรับคือ ipv4.route-metric บนการเชื่อมต่อ และบน Bullseye สิ่งที่เทียบเท่าคือบรรทัด metric เฉพาะอินเทอร์เฟซใน dhcpcd.conf. ลดความสำคัญของลิงก์ไร้สายแทนการปิดใช้งาน เพื่อให้เส้นทางย้อนกลับอยู่ห่างเพียงหนึ่งคำสั่ง

พิสูจน์อุโมงค์จากภายนอก ไม่ใช่จาก LAN

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

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

sudo journalctl -u openvpn-server@server -n 40 --no-pager
sudo tcpdump -ni any udp port 1194 -c 20

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

เก็บการย้อนกลับขั้นตอนเดียวและเลิกใช้โปรไฟล์ไร้สาย

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

การเลิกพึ่งพาไร้สายเป็นการเปลี่ยนคุณสมบัติ ไม่ใช่การลบ การตั้งค่า connection.autoconnect no ทำให้ข้อมูลรับรองและประวัติแอดเดรสยังคงอยู่ครบ ในขณะที่ Pi ถูกกันไม่ให้เชื่อมต่อกลับไปยังเครือข่ายที่คุณย้ายจากมา

nmcli con show
sudo nmcli con up "Wired connection 1"
sudo nmcli con mod "previously-used-wifi" connection.autoconnect no

ก่อนประกาศว่างานเสร็จ ให้ยืนยันสี่สิ่ง: เป้าหมายการเปลี่ยนเส้นทางตรงกับแอดเดรสแบบมีสาย listener รอดจากการรีสตาร์ต ไคลเอนต์ภายนอกทำแฮนด์เชกสำเร็จ และ Pi ยังตอบบนแอดเดรสแบบมีสายหลังรีบูต การรีบูตเป็นวิธีที่ถูกที่สุดในการจับการกำหนดที่อยู่เฉพาะในเคอร์เนลที่กำลังทำงาน หากข้อใดข้อหนึ่งจากสี่ล้มเหลว ให้ยกโปรไฟล์ไร้สายกลับขึ้นมาด้วย sudo nmcli con up แล้วเปรียบเทียบค่าที่บันทึกไว้กับค่าที่ใช้งานอยู่