VPN ค้างหลังรีบูตเราเตอร์: สามสิ่งที่เปลี่ยนไป

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

เงื่อนไขสามข้อตัดสินวิธีแก้ ตรวจตามลำดับ เพราะข้อหลัง ๆ เป็นงานเปล่าถ้าข้อแรกอธิบายการค้างได้แล้ว

เงื่อนไขที่หนึ่ง: ที่อยู่ภายในเครื่องเปลี่ยนไป

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

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

ip -4 addr show
ip route show default
ip route get 203.0.113.10

เงื่อนไขที่สอง: การแมปที่แปลงแล้วหายไป

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

นี่คือจุดที่ทันเนลที่ไม่มี keepalive หยุดเงียบ ๆ แทนที่จะล้มเหลวเสียงดัง ข้อจำกัดที่บันทึกไว้ ของ WireGuard อธิบายรูปแบบความล้มเหลวแบบเดียวกัน สถานะปลายทางที่ผิดสร้างแพ็กเก็ตที่ถูกทิ้งแทนการวินิจฉัย

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

เงื่อนไขที่สาม: ที่อยู่สาธารณะเปลี่ยนไป

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

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

กู้คืนตามลำดับที่ถูกต้อง

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

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

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