Ping ไม่ใช่หลักฐาน: ทดสอบเส้นทางระหว่างสองไซต์

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

เริ่มที่ไคลเอนต์ที่ต้องการบริการ

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

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

เดินเส้นทางที่แต่ละขอบ

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

ip route get 10.10.0.5
sudo tcpdump -ni any host 10.10.0.5 and port 445
sudo tcpdump -ni any net 10.10.0.0/24 and net 10.20.0.0/24

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

ใช้โปรโตคอลที่แอปใช้

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

nc -vz 10.10.0.5 445
curl -sv --max-time 5 https://files.corp.internal/ -o /dev/null
openssl s_client -connect 10.10.0.5:443 -servername files.corp.internal

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

ทำซ้ำเงื่อนไขที่ล้มเหลว

ความล้มเหลวที่ปรากฏเฉพาะการถ่ายโอนขนาดใหญ่เป็นปัญหาขนาด ไม่ใช่การเชื่อมต่อ ส่งแพ็กเก็ตใหญ่ที่ตั้งบิต don't-fragment แล้วดูว่ามันหยุดที่ไหน หากคำขอเล็กสำเร็จแต่คำขอใหญ่ค้าง MTU ของอุโมงค์และการจัดการ MSS ที่เกตเวย์คือผู้ต้องสงสัยรายต่อไป

ping -M do -s 1400 10.10.0.5
ping -M do -s 1472 10.10.0.5
curl -sS --max-time 30 -F file=@./sample.bin https://files.corp.internal/upload

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

หลังการแก้ไข ให้ทำแบบทดสอบเดิมซ้ำ

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

บันทึกค่าฐานสี่ค่าและผลลัพธ์ รายงานครั้งถัดไปของอาการเดียวกันจะเริ่มจากหลักฐานแทนการเริ่มจาก ping