VPN ตายหลังสลีป: อุโมงค์หายหรือแอปเก่า?

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

สามสิ่งอาจเสียหลังตื่น

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

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

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

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

อย่างแรก: อุโมงค์กลับมาหรือไม่

ดูอินเทอร์เฟซและสถานะเพียร์ ไม่ใช่ข้อความสถานะของไคลเอนต์เอง อินเทอร์เฟซที่มีที่อยู่แต่ไม่มีแฮนด์เชคล่าสุดคืออุโมงค์ที่มีอยู่แต่ชื่อ

ip -brief addr show
wg show
ip route show table all | head -20

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

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

อย่างที่สอง: มีอะไรขอให้มันกลับมาหรือไม่

ตรงนี้เองที่การเปรียบเทียบคุ้มค่า โปรไฟล์ปลั๊กอิน OpenVPN และการเชื่อมต่อ WireGuard แบบเนทีฟถูกจัดการต่างกันโดย NetworkManager และ เอกสารอ้างอิงการตั้งค่าการเชื่อมต่อ ระบุชัดว่า connection.autoconnect ไม่ได้เปิดใช้งานโปรไฟล์ VPN กลไกในการยก VPN พร้อมการเชื่อมต่อคือ connection.secondaries

nmcli connection show --active
nmcli -f connection.autoconnect,connection.secondaries connection show "Work VPN"
journalctl -u NetworkManager -b --no-pager | tail -40

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

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

อย่างที่สาม: แอปถือสถานะเก่าอยู่หรือไม่

เปิดเซสชันใหม่ทั้งหมดไปยังปลายทางเดิมก่อนแตะ VPN ถ้าเซสชันใหม่ทำงานและเซสชันเก่าไม่ทำงาน อุโมงค์ปกติดีและแอปถือการเชื่อมต่อที่ตายแล้ว

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

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

ทำให้การเปรียบเทียบทำซ้ำได้

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

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

keepalive แบบต่อเนื่องของ WireGuard อยู่ในภาพนี้ในฐานะ keepalive ของการแมป NAT เท่านั้น มันส่งแพ็กเก็ตเพื่อคงการแมปให้เปิดอยู่ มันไม่ได้ป้องกันเครื่องจากการสลีป และไม่สามารถส่งต่อได้ในขณะที่โปรเซสถูกระงับ

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