ที่อยู่ของ peer เปลี่ยนกลางเซสชัน: float ใน OpenVPN ทำอะไร

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

float ผ่อนอะไร และไม่ผ่อนอะไรเลย

โดยปกติเซสชันจะพูดคุยกับที่อยู่ภายนอกและพอร์ตที่เริ่มต้นไว้ต่อไป และแพ็กเก็ตที่มาจากที่อื่นจะถูกเพิกเฉย ตัวเลือก float จะยกเลิกการผูกที่เข้มงวดนั้นเมื่อ peer พิสูจน์ตัวเองแล้ว ดังนั้นการแมปต้นทางที่เปลี่ยนไปสามารถทำเซสชันเดิมต่อได้แทนที่จะถูกทิ้ง สิ่งใดในการตรวจสอบเชิงรหัสไม่ได้เปลี่ยน: กุญแจ ใบรับรอง และการป้องกัน HMAC ใด ๆ ยังคงเหมือนเดิมทุกประการ

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

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

แพ็กเก็ตที่ย้ายเซสชันต้องผ่านการพิสูจน์ตัวตน

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

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

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

การค้นพบเป็นกลไกที่แยกออกไปโดยสิ้นเชิง

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

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

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

เมื่อ NetworkManager เป็นเจ้าของโปรไฟล์

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

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

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

พิสูจน์การเปลี่ยนผ่านแทนที่จะสันนิษฐาน

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

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

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