Azure VM เข้าถึง IMDS หรือ WireServer ไม่ได้หลังจาก VPN เริ่มทำงาน

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

อาการดูเหมือนเอเจนต์เสีย

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

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

168.63.129.16 ไม่ใช่ปลายทางสาธารณะ

168.63.129.16 คือแอดเดรสแพลตฟอร์มเสมือนพิเศษของ Azure และหนึ่งในบทบาทคือ WireServer ที่เอเจนต์ VM ใช้คุยกับแฟบริก Microsoft ระบุว่าทราฟฟิกของเอเจนต์ไปยังพอร์ต TCP 80 และ 32526 ต้องคงพร้อมใช้งาน มันไม่ใช่โฮสต์อินเทอร์เน็ตทั่วไป และไม่ใช่สิ่งที่ VPN อุโมงค์เต็มควรพาไปยังทางออกระยะไกล นี่คือเหตุผลที่อุโมงค์ที่ดูปกติยังทำให้เอเจนต์ขาดอาหารได้

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

ถ้าเอเจนต์เป็นตัวรายงานปัญหา ให้ตรวจสอบสถานะบริการและเส้นทางไปยังแอดเดรสนั้นก่อนติดตั้งอะไรใหม่

169.254.169.254 มีกฎของตัวเอง

169.254.169.254 คือแอดเดรส link-local ของ Azure Instance Metadata Service คำขอไปยังแอดเดรสนี้มีข้อกำหนดของตัวเอง: NIC หลักและ IP หลัก การตั้งค่า DHCP ที่รองรับแอดเดรส และการข้ามพร็อกซี HTTP ใด ๆ การส่งผ่านทางออก VPN ระยะไกลหรือเกตเวย์อินเทอร์เน็ตตามอำเภอใจไม่ใช่รูปแบบการเข้าถึงที่ Microsoft อธิบาย

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

อย่าวางการตอบกลับเมตาดาตาลงในตั๋วสนับสนุนขณะแก้ปัญหานี้ มันอาจมีข้อมูลรับรองและรายละเอียดอินสแตนซ์ที่อยู่ยาวกว่าอุบัติการณ์

อ่านเส้นทางตามนโยบายของแขก ไม่ใช่แค่ตารางหลัก

บนแขก Linux คำสั่งอ่านอย่างเดียวสามคำสั่งแยกชั้นต่าง ๆ: ip -4 rule show สำหรับกฎนโยบาย จากนั้น ip -4 route get 168.63.129.16 และ ip -4 route get 169.254.169.254 สำหรับการตัดสินใจที่เคอร์เนลทำจริง รันก่อนและหลัง VPN เชื่อมต่อ ความต่างระหว่างผลลัพธ์ทั้งสองคือชุดการเปลี่ยนแปลงของคุณ และมีประโยชน์กว่าการเดาใด ๆ เกี่ยวกับสิ่งที่ไคลเอนต์ทำ

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

ต้านทานสูตรที่เพิ่มทั้งสองเส้นทาง /32 ผ่านเกตเวย์เก่า เส้นทางแพลตฟอร์ม link-local และฮอปถัดไป WAN ทั่วไปเป็นวัตถุต่างกัน และข้อยกเว้นแบบเหมารวมซ่อนความขัดแย้งของนโยบายจริง

แยกการบริหารและการกู้คืนออกจากกัน

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

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

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