VPN เชื่อมต่อแล้วแต่ที่อยู่ IP ไม่เปลี่ยน: เพราะอะไร

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

ยืนยันว่าการทดสอบวัดอะไรจริงๆ

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

ใช้เสียงสะท้อนที่อยู่สาธารณะและถามแต่ละตระกูลแยกกัน เพราะผลการทดสอบแบบ dual-stack ซ่อนกรณีที่น่าสนใจ:

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

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

โปรไฟล์อาจครอบคลุมเพียงบางส่วนของทราฟฟิก

โปรไฟล์แบบอุโมงค์แบ่งส่วนเป็นคำตอบทั่วไป และไม่ใช่ข้อบกพร่อง OpenVPN ส่งทุกอย่างผ่านอุโมงค์เฉพาะเมื่อ redirect-gateway อยู่ในตัวเลือกที่พุชลงมา หากไม่มี ไคลเอนต์จะได้รับเส้นทางเฉพาะจำนวนหนึ่งและเส้นทางเริ่มต้นของคุณยังอยู่บนลิงก์กายภาพ บน Windows สวิตช์เดียวกันปรากฏเป็น «ใช้เกตเวย์เริ่มต้นบนเครือข่ายระยะไกล» ในคุณสมบัติ IPv4 ของอะแดปเตอร์ และการเอาออกเป็นการเลือกโดยเจตนาที่อยู่รอดทุกการเชื่อมต่อใหม่

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

ตระกูลที่อยู่หนึ่งยังคงออกได้โดยตรง

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

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

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

เส้นทางที่สองอาจชนะการค้นหา

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

ทำบัญชีก่อนเปลี่ยนสิ่งใด ด้วยคำสั่งอ่านเท่านั้น:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

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

วัดใหม่ด้วยคำขอใหม่

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

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