ย้ายเซิร์ฟเวอร์ VPN ไปยัง IP สาธารณะใหม่: ต้องตรวจอะไรก่อน
การสลับในที่และการตัด-over แบบขนานพังคนละจุด ตรวจสอบคอนฟิก NAT และใบรับรอง แล้วดูว่าไคลเอนต์แต่ละตัวแก้ชื่ออย่างไร
การกำหนดที่อยู่ใหม่ใช้เวลาหนึ่งนาที สัปดาห์ถัดมาคือจุดที่การย้ายพัง และแทบไม่เคยเป็นจุดที่คอนโซลของผู้ให้บริการแนะนำ IP สาธารณะใหม่ถูกอ้างถึงในสี่ที่: ซ็อกเก็ตที่แดมอนฟังอยู่ สมอยึดความเชื่อถือที่ไคลเอนต์ตรวจสอบ ทุกกฎที่ระบุที่อยู่เก่า และ ระเบียน DNS ที่ผูกเข้าด้วยกัน การย้ายสองแบบดูเหมือนกันจากแผงควบคุมแต่ทำงานต่างกันโดยสิ้นเชิง: กำหนดที่อยู่ใหม่บนเครื่องที่คุณดูแล หรือตั้ง endpoint ที่สองและย้ายไคลเอนต์ไปที่นั่น การตรวจด้านล่างวางความล้มเหลวราคาถูกไว้ก่อน และแต่ละส่วนระบุว่าใช้กับการย้ายแบบใด
การสลับในที่และการตัด-over แบบขนานเป็นงานคนละอย่าง
การสลับในที่เก็บโฮสต์ กุญแจ ตารางเส้นทาง และรายชื่อผู้ใช้ไว้ มีเพียงที่อยู่ที่เปลี่ยน นั่นคือสิ่งที่การกำหนด IP ลอยใหม่ทำ และผู้ให้บริการหลายรายผู้เยี่ยมชมไม่รู้ตัวเลย เพราะการแปลเกิดขึ้นหน้าเพลตฟอร์ม การสร้างใหม่หรือการกำหนดใหม่โดยผู้ให้บริการนั้นหนักกว่า: ผู้เยี่ยมชมเห็นการเปลี่ยนแปลง และทุกอย่างที่แคชค่าเก่าไว้ก็รู้เรื่องในชั่วขณะเดียวกัน
endpoint แบบขนานคือโฮสต์ที่สองที่ทำงานเดียวกัน สร้างมัน ทดสอบด้วยโปรไฟล์เดียว และปล่อยให้ตัวเก่าตอบจนกว่าตัวใหม่จะพิสูจน์ตัวเองบนเส้นทางจริง ราคาคือสถานะ หากไม่มีรายการ peer การเพิกถอน และการบันทึกที่ใช้ร่วมกัน คุณมีสองเครือข่ายที่บังเอิญใช้ชื่อเดียวกัน
| Question | In-place swap | Parallel endpoint |
|---|---|---|
| Rollback in one step? | Only if you can get the old address back | Point DNS back; old host still up |
| Blast radius | Every client at once | Only the clients you moved |
| Best when | The address is yours to reassign | The old address is gone for good |
หาทุกที่ที่ที่อยู่เก่าถูกเขียนไว้
เริ่มด้วยการค้นข้อความ เพราะไฟล์คอนฟิกเป็นครึ่งที่ง่าย ค้นในคอนฟิกแดมอน ชิ้นส่วนไฟร์วอลล์ เป้าหมายการมอนิเตอร์ และบันเดิลไคลเอนต์ที่สร้างขึ้นบนดิสก์ รวมที่อยู่ IPv6 ด้วยหากคุณเผยแพร่ ที่ย้ายที่ตามเพียงระเบียน A จะทิ้งไคลเอนต์ดูอัลสแตกไว้บนเส้นทางเก่า
OLD=203.0.113.10
grep -RIn -- "$OLD" /etc /root
ss -lunpt | grep -F "$OLD"
nft list ruleset | grep -F "$OLD"
iptables-save | grep -F "$OLD"
wg show all endpointsจากนั้นตรวจเคอร์เนล เพราะระบบที่ทำงานอยู่ถือที่อยู่ในที่ที่ไม่มีไฟล์ใดกล่าวถึง กฎ NAT ต้นทางแบบสถิต รายการ ipset ที่อยู่ bind และรายการ conntrack มีอายุยืนกว่าการแก้คอนฟิกที่ลบมันออก และบางรายการรอดการรีบูตเพราะกลับมาจากชุดกฎที่บันทึกไว้ ขึ้นไปอีกชั้น กลุ่มความปลอดภัยของผู้ให้บริการ เป้าหมายโหลดบาลานเซอร์ และการตรวจมอนิเตอร์ไม่ได้อยู่ในระบบไฟล์ของคุณเลย
เขียนบัญชีทรัพย์สินก่อนเปลี่ยนสิ่งใด เพราะยังใช้เป็นสคริปต์ย้อนกลับได้
ไคลเอนต์ที่ใช้ชื่อโฮสต์ฟื้นตัว ส่วนไคลเอนต์ที่ใช้ IP ตรงตัวเงียบไป
ถ้าไคลเอนต์เข้าถึงเซิร์ฟเวอร์ด้วยชื่อโฮสต์ การตัด-over เป็นปัญหาหลักของ DNS และ TTL ที่คุณตั้งไว้เมื่อวานเป็นตัวกำหนดว่าจะแย่แค่ไหน ตัวแก้ชื่อแคช ตัวแก้ชื่อ stub แคชอีกครั้ง และไคลเอนต์จำนวนมากค้นชื่อเฉพาะเมื่อเชื่อมต่อใหม่ อุโมงค์ที่สร้างไว้แล้วจึงคงที่อยู่เริ่มต้นไว้
ถ้า endpoint เป็นที่อยู่ตรงตัว ไม่มีอะไรแก้ใหม่และไม่มีอะไรบันทึกข้อร้องเรียน WireGuard เก็บที่อยู่ซ็อกเก็ตที่แก้แล้ว: Endpoint = vpn.example.net:51820 กลายเป็น IP ทันทีที่ wg-quick up ทำงาน และคงเป็น IP นั้นจนกว่าคุณจะเปลี่ยน OpenVPN ยืดหยุ่นกว่า: แก้ชื่อโฮสต์ remote ตอนเชื่อมต่อ และด้วย resolv-retry infinite จะลอง DNS อีกครั้งเมื่อเชื่อมต่อใหม่ เมื่อให้ IP ตรงตัว ทั้งคู่ยังคงหมุนหาเครื่องที่ไม่มีอยู่แล้ว
สิ่งที่หลอกคนคือภาพกระจก ไคลเอนต์ที่ชี้ไปที่อยู่ใหม่แล้วในขณะที่ผู้ฟังเก่ายังตอบอยู่ ผ่านทุกการทดสอบที่คุณทำจากโต๊ะของคุณเอง ผมก็เคยถูกหลอกด้วยสิ่งนี้: endpoint ใหม่ขึ้นบนโทรศัพท์ได้ในการลองครั้งแรก และไคลเอนต์ที่มีโปรไฟล์เก่าก็ปรากฏเมื่อปิดผู้ฟังเก่าไปนานมากแล้ว
ความเชื่อถือไม่ย้ายไปกับที่อยู่
WireGuard แยกอัตลักษณ์ออกจากการเข้าถึง ซึ่งทำให้การย้ายที่อยู่แทบไม่มีค่าใช้จ่าย peer ถูกระบุด้วยกุญแจสาธารณะ และ endpoint เป็นเพียงที่ที่แพ็กเก็ตไปตอนนี้ โฮสต์อัปเดต endpoint ของ peer จากที่อยู่ต้นทางของแพ็กเก็ตล่าสุดที่ตรวจสอบแล้ว peer ที่ไม่ได้ใช้งานยังต้องมีเหตุผลคุยกับที่ใหม่ และจะเรียนรู้ที่อยู่ก็ต่อเมื่อเซสชันแก่ลงและการลอง handshake ซ้ำล้มเหลวในที่ที่มองเห็นได้ คู่มือเริ่มต้นอย่างรวดเร็วของ WireGuard ครอบคลุมฟิลด์ endpoint
เซิร์ฟเวอร์ที่ใช้ TLS คือกรณีตรงข้าม ใบรับรองผูกกับชื่อ และไคลเอนต์ที่หมุนที่อยู่จะเทียบสิ่งที่หมุนกับชื่อทางเลือกของ subject เชื่อมต่อด้วย IP ไปยังใบรับรองที่มีเพียง DNS SAN และการตรวจสอบล้มเหลว: ชื่อที่ไคลเอนต์ใช้ไม่อยู่ในใบรับรอง การออกใหม่ด้วย IP SAN แก้การเชื่อมต่อนั้นและทำให้การย้ายครั้งถัดไปแย่ลง การเก็บชื่อโฮสต์ไว้ในโปรไฟล์และปล่อย verify-x509-name ไว้ที่เดิมทำให้การตรวจยังเข้มงวดในขณะที่ที่อยู่ข้างใต้เปลี่ยน
จากนั้นตรวจว่าแดมอนผูกกับอะไร ซ็อกเก็ตที่ปักไว้กับที่อยู่เก่าล้มเหลวอย่างเงียบ ๆ เซิร์ฟเวอร์ OpenVPN ที่เริ่มด้วย local 203.0.113.10 จะไม่ยอมขึ้นเมื่อที่อยู่นั้นหายไป ขณะที่ผู้ฟังบน 0.0.0.0 ตามการเปลี่ยนแปลงได้ฟรี NAT ก็แยกแบบเดียวกัน: MASQUERADE ตามที่อยู่ที่เครื่องมีตอนนี้ และ SNAT --to-source 203.0.113.10 แบบสถิตยังคงเขียนใหม่ไปยังที่อยู่ที่คุณไม่ได้เป็นเจ้าของแล้ว ปริมาณการรับส่งกลับจึงหายไป หากที่อยู่ใหม่มาพร้อมเกตเวย์ upstream ที่ต่างออกไป ตรวจ rp_filter: การกรองเส้นทางย้อนกลับทิ้งปริมาณการรับส่งกลับที่มาถึงอินเทอร์เฟซที่เคอร์เนลไม่ได้คาดไว้
ลำดับการตัด-over และหลักฐานว่ามันได้ผล
ลด TTL ล่วงหน้าหนึ่งวัน ตั้งผู้ฟังใหม่ และพิสูจน์ด้วยโปรไฟล์ที่มีเพียงคุณ การทดสอบจากภายในเครือข่ายเดียวกันแทบไม่พิสูจน์อะไรเลย จึงใช้โทรศัพท์บนเซลลูลาร์และทดสอบสิ่งที่อุโมงค์ควรลำเลียงแทนการ ping ไปที่ endpoint
เฝ้าดูทั้งสองที่อยู่ตลอดหน้าต่าง wg show all latest-handshakes บนโฮสต์ใหม่ หรือไฟล์สถานะของ OpenVPN บอกคุณว่ามีกี่ peer ที่ย้ายจริง เมื่อ endpoint ใหม่มี peer ที่คุณคาดหวังและตัวเก่าเหลือเพียงผู้ตามหลัง ให้ปลดระวางผู้ฟังเก่า ลบกฎ NAT ที่ล้าสมัย และถอดที่อยู่ออกจากไฟร์วอลล์ของผู้ให้บริการ การลบผู้ฟังเก่าคือขั้นตอนที่มักถูกข้าม และมันปิดช่องที่โปรไฟล์เก่ายังไปถึงเครือข่ายเก่า
กำหนดตัวกระตุ้นการย้อนกลับเป็นลายลักษณ์อักษรก่อนเริ่ม: หาก endpoint ใหม่ไม่มีการ handshake จากไคลเอนต์จริงแม้แต่ตัวเดียวหลังหน้าต่างที่ตกลง ให้คืนที่อยู่เก่าและหยุดแจกจ่ายโปรไฟล์ จากนั้นรันการค้นซ้ำและยืนยันว่ายังไม่มีผู้ฟังใดผูกกับที่อยู่ที่ปลดระวางแล้ว สองสิ่งจะส่งต่อไปยังการย้ายครั้งถัดไป: ชื่อโฮสต์ในโปรไฟล์ไคลเอนต์เพื่อให้การเปลี่ยนแปลงครั้งถัดไปเป็นการแก้ DNS และบัญชีทรัพย์สินที่เก็บไว้ข้างบันทึกการกู้คืนของเซิร์ฟเวอร์