VPN เชื่อมต่อได้แต่เข้าถึงอุปกรณ์ LAN ไม่ได้: ต้องตรวจสอบอะไร

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

จากนี้ไปให้ทดสอบอะไรบางอย่างที่อีกด้านของเกตเวย์ ที่อยู่ของเกตเวย์เองจะยังคงตอบกลับ ไม่ว่าการส่งต่อจะเสียหายแค่ไหน

เกตเวย์ตอบจากสแตกของตัวเอง

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

หน้าเว็บผู้ดูแลระบบที่เข้าถึงผ่านทันเนลก็อยู่ในหมวดแรกเช่นกัน มันเป็นหลักฐานเกี่ยวกับทันเนล ไม่ใช่เกี่ยวกับเครือข่ายด้านหลัง

ติดตามเส้นทางไปจนถึงขอบเขตแรกที่ทิ้งมัน

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

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

เส้นทางกลับและไฟร์วอลล์ของโฮสต์ล้มเหลวแยกกัน

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

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

ยืนยันทุกฮอปด้วยที่อยู่ต้นทางของผู้ใช้

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

ip route get 192.168.50.20 from 10.8.0.2
ping -I 10.8.0.2 -c 3 192.168.50.20
sudo tcpdump -ni tun0 host 192.168.50.20
sudo tcpdump -ni br0 host 192.168.50.20

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

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