ทำไม traceroute ถึงตายเพียงทิศทางเดียวผ่านอุโมงค์ VPN

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

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

ดาวคือคำตอบที่หายไป ไม่ใช่ฮอปที่หายไป

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

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

วิธีตรวจสอบเป็นตัวกำหนดว่าคุณจะพบฟิลเตอร์ใด

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

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

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

เส้นทางกลับเป็นเส้นทางของตัวเอง

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

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

ยืนยันอุโมงค์ด้วยคำขอจริง

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

traceroute -I -n -w 2 203.0.113.40
traceroute -T -p 443 -n -w 2 203.0.113.40
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' --max-time 5 http://203.0.113.40:8080/health
ss -tan state established

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

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