ทราฟฟิกขากลับของ Azure P2S VPN ทำงานได้ทางเดียวเท่านั้น

ไอคอนอุโมงค์เป็นสีเขียว NSG ดูเหมือนอนุญาต เส้นทางที่มีผลดูถูกต้อง แต่ VM ก็ยังเปิดการเชื่อมต่อกลับไปยังไคลเอนต์ที่เชื่อมต่ออยู่ไม่ได้ ข้อสันนิษฐานทั่วไปคืออุโมงค์ point-to-site ที่ทำงานได้นั้นสมมาตร: ถ้าไคลเอนต์ไปถึง VM ได้ VM ก็ไปถึงไคลเอนต์ได้ ข้อสันนิษฐานนั้นคือข้อผิดพลาดในการให้เหตุผล ไม่ใช่ในการกำหนดค่า อุโมงค์สามารถพาทิศทางหนึ่งของโฟลว์ที่ไม่ได้รับการร้องขอและทิ้งอีกทิศทางหนึ่ง และการแก้ไขขึ้นอยู่กับว่าชั้นใดเป็นผู้ทิ้ง

ความเชื่อผิด: อุโมงค์ที่เชื่อมต่ออยู่คืออุโมงค์สองทิศทาง

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

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

ทดสอบทิศทางก่อนทดสอบการเข้าถึง

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

ขั้นตอนต่อไปคือหลักฐาน ไม่ใช่กฎเพิ่มเติม ตรวจสอบ NSG บนซับเน็ตของ VM ทั้งสองทิศทาง อ่านเส้นทางที่มีผลบน NIC ของ VM และจับแพ็กเก็ตบน VM ขณะที่ไคลเอนต์ส่งทราฟฟิก คำขอที่มาถึงโดยไม่มีคำตอบคือปัญหาไฟลเตอร์หรือเส้นทางขากลับ คำขอที่ไม่เคยมาถึงคือปัญหาเส้นทาง อย่าถือว่า ping ที่ล้มเหลวเป็นหลักฐานว่า VM เข้าถึงไม่ได้ เพราะนโยบาย ICMP อาจทิ้งคำตอบในขณะที่ TCP ยังทำงานได้

เส้นทางขากลับของ IKEv2 point-to-site คือผู้ต้องสงสัยตามปกติ

ในรายงาน Azure ที่อยู่เบื้องหลังบทความนี้ ไคลเอนต์สามารถไปถึง VM ผ่าน IKEv2 ได้ แต่ ICMP ขาเข้าจาก VM ไปยังไคลเอนต์ล้มเหลวจนกว่าจะเปลี่ยนชนิดอุโมงค์ของเกตเวย์เป็น OpenVPN ผู้เขียนรายงานกล่าวว่า Microsoft ยืนยันข้อจำกัดในเส้นทาง IKEv2 point-to-site ซึ่งทราฟฟิกขากลับจาก VM ไปยังไคลเอนต์ไม่ได้ถูกกำหนดเส้นทางอย่างสมมาตรเว้นแต่ไคลเอนต์จะเป็นผู้เริ่มเซสชัน IKEv2 อาศัยตัวเลือกทราฟฟิก และเกตเวย์ไม่ได้เคารพทิศทางขากลับในกรณีนั้น

นั่นไม่ได้ทำให้ OpenVPN เป็นชนิดอุโมงค์ที่ดีกว่าโดยทั่วไป แต่ทำให้ชนิดอุโมงค์เป็นตัวแปรในเมทริกซ์การทดสอบสำหรับภาระงานนี้

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

ความเชื่อผิด: การค้นหาผ่าน broadcast ข้ามขอบเขต VNet

ข้อสันนิษฐานที่สองล้มเหลวด้วยเหตุผลที่ไม่เกี่ยวข้อง เครือข่ายเสมือนของ Azure ไม่พาทราฟฟิก broadcast ดังนั้น VM จึงไม่สามารถรับเฟรม broadcast จากเครือข่ายภายในองค์กรผ่านการเชื่อมต่อ site-to-site หรือ point-to-site ได้ แอปพลิเคชันที่ค้นหาเพื่อนผ่าน broadcast เช่นการเรียกดูไฟล์แบบเก่าหรือโปรโตคอลค้นหาอุปกรณ์บางตัว จะไม่เห็นฝั่งปลายทางเลยไม่ว่าจะเขียนเส้นทางอย่างไร

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

จะเปลี่ยนอะไร และจะพิสูจน์อย่างไร

หากการทดสอบทิศทางล้มเหลวเฉพาะบน IKEv2 ให้บันทึกชนิดอุโมงค์ของเกตเวย์ พูลที่อยู่ไคลเอนต์ และการทดสอบ ICMP หรือ TCP ที่แน่นอน จากนั้นประเมินโปรไฟล์ OpenVPN ที่ได้รับอนุมัติสำหรับไคลเอนต์ที่ได้รับผลกระทบ หากล้มเหลวในทุกชนิดอุโมงค์ ให้ทำงานกับเส้นทางขากลับ: ที่อยู่ไคลเอนต์ต้องกำหนดเส้นทางได้จากซับเน็ตของ VM เส้นทางที่ผู้ใช้กำหนดต้องชี้ไปยังฮอปถัดไปที่ถูกต้อง และไฟร์วอลล์ของไคลเอนต์ต้องยอมรับโฟลว์ขาเข้า แนบหลักฐาน NSG และเส้นทางไปกับตั๋ว

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