VPN ย้ายที่แล้ว: ทำไมไคลเอนต์ OpenVPN ของคุณยังหมุนไปที่ IP เดิม

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

ดูว่าโปรไฟล์หมุนไปที่ไหน ไม่ใช่ DNS พูดอะไร

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

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

สองไฟล์ ปลายทางเดียว นี่คือสิ่งที่พบได้บ่อยที่นี่

grep -nE '^remote|^resolv-retry|^persist-remote-ip|^float' client.ovpn
printf 'resolver says: '; dig +short vpn.example.net

อ่านความพยายามเชื่อมต่อครั้งถัดไปของไคลเอนต์

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

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

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

รู้ว่าคุณกำลังรีสตาร์ตแบบไหน

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

การตั้งค่าความคงอยู่ก็สำคัญ เพราะออกแบบมาเพื่อรักษาสิ่งที่ผ่านการพิสูจน์ตัวตนแล้ว ไม่ใช่ไล่ตามที่อยู่ใหม่

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

สี่ตัวเลือกและงานที่แยกจากกัน

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

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

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

ยืนยันปลายทางใหม่ก่อนโทษไคลเอนต์

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

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

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