แคชเส้นทาง VPN ซ่อนการเปลี่ยนแปลงของคุณอยู่หรือเปล่า? ตรวจสอบสามสิ่ง

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

การตรวจสอบหนึ่ง: เส้นทางเก่ามาจากโฟลว์ใหม่หรือไม่

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

ss -tnp | head
ip route get 1.1.1.1
curl -m 5 -sS -o /dev/null -w '%{remote_ip}
' https://example.com

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

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

การตรวจสอบสอง: แพลตฟอร์มของคุณเก็บแคชเส้นทางหรือไม่

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

แพลตฟอร์มอื่นแตกต่างออกไป และนี่คือจุดที่การคัดลอกคำแนะนำผิดพลาด วินโดวส์เก็บแคชปลายทางที่คุณล้างได้ด้วย netsh interface ip delete destinationcache BSD และ macOS แสดงการค้นหาตามปลายทางผ่าน route -n get และแคชของมันหมดอายุตามกำหนดของตัวเอง คำสั่งที่ใช้ได้บนหนึ่งในนั้นไม่ทำอะไรเลยบนลินุกซ์ ซึ่งเป็นเหตุผลที่วิธีแก้เดียวกันดูเหมือนล้มเหลวสำหรับครึ่งหนึ่งของผู้ที่ลอง

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

การตรวจสอบสาม: สถานะอยู่ในเราเตอร์หรือเหนือขึ้นไป

อ่านการค้นหาปัจจุบันก่อนอ่านอย่างอื่น: ip route get สำหรับปลายทาง จากนั้นคำสั่งเดิมพร้อม from และที่อยู่ต้นทาง จากนั้น ip rule show ถ้าสามอย่างนี้ตรงกับที่คุณตั้งใจ เราเตอร์ไม่ใช่ชั้นที่ต้องแก้ และการสังเกตที่ค้างเก่ามาจากที่อื่น

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

สามคำตอบทำให้คุณสรุปอะไรได้

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

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

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

แยกสถานะสามอย่างไว้ในบันทึกของคุณ

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

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