Linux EHOSTUNREACH กับ OpenVPN: ฮอปถัดไปใดล้มเหลว?

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

เลือกที่อยู่และเนมสเปซที่ไคลเอนต์ใช้จริง

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

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

ip -4 route get 198.51.100.25
ip -4 neigh show 198.51.100.1
ip -4 route show table all | grep -w unreachable

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

เส้นทาง unreachable ที่ชัดเจนปฏิเสธแพ็กเก็ตในเครื่อง

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

ประเภทของเส้นทางใช้แทนกันไม่ได้ blackhole ทิ้งแพ็กเก็ตโดยไม่แจ้งข้อผิดพลาดแก่ผู้ส่ง prohibit คืน EACCES และ unreachable คืน EHOSTUNREACH ตัวช่วย VPN ที่ติดตั้งเส้นทาง sink ระหว่างเชื่อมต่อใหม่จึงอาจสร้างข้อผิดพลาด host-unreachable เป็นกลุ่มซึ่งหายไปเมื่ออุโมงค์ขึ้น ขณะที่เส้นทาง blackhole จะทำให้เกิดการหมดเวลาแบบเงียบแทน

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

เพื่อนบ้านที่ตายแล้วทำให้เกิดข้อผิดพลาดเดียวกันบนอีเทอร์เน็ต

เมื่อเส้นทางที่เลือกใช้เกตเวย์แบบ on-link การส่งต้องมีที่อยู่ชั้นลิงก์ที่แปลงแล้ว เคอร์เนลส่ง ARP หรือการสอบถามเพื่อนบ้าน IPv6 และหากไม่มีคำตอบกลับมา แพ็กเก็ตก็ประกอบเฟรมไม่ได้ การส่งจึงล้มเหลวด้วย EHOSTUNREACH แม้เส้นทางเองจะถูกต้อง

ตารางเพื่อนบ้านบอกระยะ INCOMPLETE หมายถึงกำลังแปลงที่อยู่ FAILED หมายถึงความพยายามล่าสุดไม่ได้รับคำตอบ และ REACHABLE หรือ STALE หมายถึงเคอร์เนลมีที่อยู่ที่ใช้ได้ รายการ FAILED สำหรับเกตเวย์ VPN คือปัญหาการส่งในเครื่อง ไม่ใช่หลักฐานเกี่ยวกับอีกฝั่งของอุโมงค์

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

รายงานจากระยะไกลและข้อผิดพลาด UDP แบบอะซิงโครนัส

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

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

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

แยกชั้นก่อนเปลี่ยนการเข้ารหัส

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

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

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