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

การตัดสินใจขึ้นอยู่กับข้อเท็จจริงสามข้อ

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

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

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

ติดตาม binding request หนึ่งรายการไปตามเส้นทาง

binding request ของ STUN ขอให้เซิร์ฟเวอร์รายงานที่อยู่ขนส่งต้นทางที่มันสังเกตเห็น คำตอบอธิบายเส้นทางที่คำขอใช้ไป ไม่ใช่รายการอินเทอร์เฟซบนเครื่องไคลเอนต์ คำขอสองรายการผ่านสองเส้นทางจะรายงานที่อยู่ต่างกันสองที่อย่างซื่อตรง

Path takenSource the reflector seesWhat it means
Tunnel to a public exit that translatesThe exit's public addressThe reflector learns nothing about the LAN
Tunnel to a private reflector, translated to the tunnel address, no later translationThat tunnel addressAn internal identifier is disclosed to that reflector
Excluded flow over the ordinary WANThe WAN addressThe tunnel was not used at all

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

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

ที่อยู่ของอุโมงค์บนเราเตอร์ไม่ใช่สิ่งใด

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

การส่งต่อคือสิ่งที่เชื่อมทั้งสองเข้าด้วยกัน คำขอข้ามเราเตอร์ในฐานะทราฟฟิกที่ถูกกำหนดเส้นทาง และต้นทางของมันคือสิ่งที่การกำหนดเส้นทางและการแปลสร้างขึ้น

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

การเปิดเผยกับการข้าม: สิ่งที่พบสองอย่าง การแก้ไขสองอย่าง

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

WebRTC ทำให้เรื่องนี้มองเห็นได้ชัดขึ้นโดยไม่ทำให้ผิด เพราะการรวบรวมผู้สมัครไม่เหมือนกับการเลือกผู้สมัคร

ip route get 203.0.113.7 from 192.0.2.25
ip rule show

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

บทความที่เกี่ยวข้อง