ตารางเส้นทางเทียบกับการค้นหาจริง: ทราฟฟิก VPN ไปที่ไหน

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

ตารางคือชุดของผู้สมัคร ไม่ใช่การตัดสินใจ

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

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

ip route get 198.51.100.10
ip route get 198.51.100.10 from 10.80.0.25
ip -6 route get 2001:db8:10::40

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

การค้นหาไล่ผ่านกฎก่อน แล้วจึงไล่ผ่านตาราง

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

ip rule show
ip route show table all | head -40
ip route show table 100

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

IPv6 มีกฎและตารางของตัวเอง การออกแบบที่รันทั้งสองตระกูลต้องมีการค้นหาทั้งสองแบบ และคำตอบ IPv4 ที่ใช้งานได้ไม่ได้บอกอะไรเกี่ยวกับเส้นทาง v6 ที่ไคลเอนต์สองสแต็กอาจต้องการ

ไคลเอนต์ VPN ติดตั้งอะไร

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

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

ip route show | grep -E 'tun|wg|ppp|ipsec'
ip route get 10.20.30.40 from 10.80.0.25

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

เส้นทางภายนอกก็ต้องอยู่รอดเช่นกัน

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

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

ip route get 203.0.113.10
traceroute -n -m 5 203.0.113.10

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

สิ่งที่เอาต์พุตการกำหนดเส้นทางบอกคุณไม่ได้

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

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

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