กำหนดเส้นทางทราฟฟิกระหว่างสองสาขาผ่านเกตเวย์ VPN ของ Azure
การเชื่อมต่อแบบไซต์ทูไซต์สองรายการบนเกตเวย์ VPN ของ Azure หนึ่งเกตเวย์สามารถส่งทราฟฟิกของสาขาได้ แต่เฉพาะเมื่อปลายทั้งสองเรียนรู้คำนำหน้าและมีเส้นทางกลับใน LAN
สองสาขาสามารถแลกเปลี่ยนทราฟฟิกผ่านเกตเวย์ VPN ของ Azure ได้โดยไม่ต้องมีทันเนลตรงระหว่างกัน แต่ละสาขาเปิดการเชื่อมต่อแบบไซต์ทูไซต์ไปยังเกตเวย์เดียวกัน และเกตเวย์ส่งคำนำหน้าที่เรียนรู้แล้วระหว่างการเชื่อมต่อทั้งสอง สิ่งที่ทำให้วิธีนี้ทำงานไม่ใช่ทันเนลที่สองแต่คือการแลกเปลี่ยนเส้นทาง: สาขา A ต้องเรียนรู้คำนำหน้าของสาขา B และ B ต้องเรียนรู้คำนำหน้าของ A ให้ทำการตรวจสอบด้านล่างตามลำดับและหยุดที่รายการแรกที่ล้มเหลว เพราะทุกขั้นตอนถัดไปขึ้นอยู่กับรายการนั้น
ข้อกำหนดเบื้องต้น ก่อนกำหนดค่าใด ๆ
มีสี่เงื่อนไขที่ตัดสินว่าการออกแบบนี้จะทำงานได้หรือไม่ เกตเวย์ต้องอิงตามเส้นทางและอยู่บน SKU ที่รองรับ BGP การเชื่อมต่อทั้งสองต้องเปิด BGP อยู่ พื้นที่แอดเดรสของสาขาต้องไม่ทับซ้อนกัน และไม่มีฝ่ายใดพึ่งพา NAT เพื่อซ่อนคำนำหน้าจริงของตน
วางแผน ASN อย่างตั้งใจ ค่าเริ่มต้นที่เอกสารของ Azure ระบุคือ 65515 และเราเตอร์ของแต่ละสาขาต้องมี ASN ส่วนตัวของตนเองที่ไม่ชนกับเกตเวย์หรืออีกสาขา การนำค่าเริ่มต้นกลับมาใช้โดยไม่ตรวจสอบการกำหนดค่าเกตเวย์ที่มีอยู่คือวิธีที่เส้นทาง AS จะถูกปฏิเสธในภายหลัง
ตรวจสอบด้วยว่าคุณไม่ได้คาดหวังพฤติกรรม peering ของ VNet เกตเวย์แลกเปลี่ยนเส้นทางระหว่างการเชื่อมต่อสองรายการที่คุณกำหนดค่าไว้ มันไม่ได้ทำให้ peering โดยพลการส่งต่อได้ หากเครือข่ายที่สามต้องเข้าถึงทั้งสองสาขา เครือข่ายนั้นต้องมีการเชื่อมต่อของตนเองหรือเส้นทางของตนเอง ไม่ใช่สมมติฐานว่าเกตเวย์จะกระจายทราฟฟิกให้ จดขอบเขตนั้นไว้ก่อนหน้าต่างเปลี่ยนแปลงครั้งแรก เพราะนี่คือการตัดสินใจออกแบบที่ผู้คนกลับมาทบทวนเมื่อมีการเพิ่มไซต์ในภายหลัง
กำหนดค่าตามลำดับนี้
แต่ละขั้นตอนมีผลลัพธ์ที่สังเกตได้ ดังนั้นอย่าไปต่อจนกว่าจะปรากฏ
- เปิด BGP บนเกตเวย์เครือข่ายเสมือนและบันทึก ASN กับที่อยู่เพียร์ของมัน
- สร้างเกตเวย์เครือข่ายภายในสำหรับแต่ละสาขาด้วยพื้นที่แอดเดรสจริงของสาขานั้น ASN และที่อยู่เพียร์ BGP ของมัน
- สร้างการเชื่อมต่อแบบไซต์ทูไซต์แต่ละรายการและเปิด BGP บนตัวการเชื่อมต่อนั้น
- กำหนดค่าเราเตอร์ของสาขาให้เพียร์กับที่อยู่เกตเวย์ที่ Azure กำหนดให้ ไม่ใช่จุดสิ้นสุด IKE สาธารณะของเกตเวย์ตามสมมติฐาน
ขั้นตอนที่สี่คือจุดที่ความพยายามส่วนใหญ่ติดขัด ที่อยู่เพียร์ BGP ที่ Azure รายงานคือที่อยู่ที่เราเตอร์ของสาขาต้องใช้เป็นเพื่อนบ้าน และไม่ใช่ที่อยู่ที่ผู้คนคาดหวังจากแผนภาพทันเนลเสมอไป
ประกาศคำนำหน้าของสาขาเอง เช่น 10.10.0.0/16 จาก A และ 10.20.0.0/16 จาก B อย่าประกาศเส้นทางเริ่มต้นหรือการรวมแบบกว้างเพื่อครอบคลุมเครือข่ายเฉพาะที่ขาดหาย ช่องว่างนั้นจะกลับมาในภายหลังเป็นหลุมดำเงียบ ๆ
ตรวจสอบการแลกเปลี่ยนเส้นทางที่ปลายทั้งสอง
สถานะการเชื่อมต่อไม่ใช่การตรวจสอบ IPsec อาจทำงานอยู่บนการเชื่อมต่อทั้งสองขณะที่ไม่มีคำนำหน้าใดข้ามระหว่างกัน อ่านเพียร์ BGP ของเกตเวย์และเส้นทางที่เรียนรู้ แล้วยืนยันว่าเส้นทางไปยังอีกสาขาปรากฏเป็นเส้นทางที่ใช้งานได้
| Check | Where | Stop if |
|---|---|---|
| BGP session established | Gateway BGP peers, branch router neighbour state | Session is Idle or Active on either side |
| Prefix learned | Gateway learned routes, branch BGP table | The other branch's prefix is absent |
| Prefix selected | Branch routing table, effective routes on the VNet | Prefix is known but a more specific route wins |
คำนำหน้าที่อยู่ในตาราง BGP ยังอาจแพ้การตัดสินใจส่งต่อให้กับเส้นทางแบบคงที่หรือคำนำหน้าที่เฉพาะเจาะจงกว่า ตรวจสอบเส้นทางที่เลือก ไม่ใช่เพียงเส้นทางที่ได้รับ
ตามเส้นทางกลับฝั่ง LAN
นี่คือส่วนที่ดูถูกต้องใน Azure แต่ล้มเหลวที่หน้างาน โฮสต์ในสาขา A จะส่งแพ็กเก็ตไปยังเราเตอร์ VPN ของ A ก็ต่อเมื่อเราเตอร์นั้นเป็นเกตเวย์เริ่มต้นของโฮสต์ หรือเมื่อโฮสต์หรือเกตเวย์ของโฮสต์มีเส้นทางไปยังคำนำหน้าของ B ต้องเป็นเช่นเดียวกันในทิศทางกลับ
หากสวิตช์แกนกลางแยกต่างหากเป็นเกตเวย์เริ่มต้นของ LAN สวิตช์นั้นต้องมีเส้นทางไปยังอีกสาขาที่ชี้ไปยังเราเตอร์ VPN หากไม่มี คำขอจะมาถึงแต่คำตอบออกไปทางเส้นทางอินเทอร์เน็ต และผู้ใช้เห็นการเชื่อมต่อที่เปิดแล้วค้าง
อย่าหันไปพึ่งกลุ่มความปลอดภัยเครือข่ายบนซับเน็ตของเกตเวย์เพื่อแก้ปัญหานี้ ซับเน็ตนั้นมีข้อกำหนดของตัวเอง และ NSG ที่นั่นไม่ใช่สิ่งทดแทนนโยบายฝั่งสาขาที่ได้รับการสนับสนุน การกรองควรอยู่บนไฟร์วอลล์ของสาขาและบนเวิร์กโหลดเอง ซึ่งเจ้าของสามารถตรวจทานกฎได้ การย้ายกฎเหล่านั้นไปยัง NSG ของซับเน็ตยังซ่อนกฎจากทีมที่จะดีบักเหตุขัดข้องครั้งถัดไปด้วย
อนุญาตการทำงาน แล้วพิสูจน์ด้วยการทดสอบที่ถูกปฏิเสธ
เส้นทางที่เรียนรู้ไม่ใช่การอนุญาต อนุญาตแหล่งที่มา ปลายทาง และบริการที่คุณต้องการจริงผ่านไฟร์วอลล์ของสาขาและนโยบายปลายทาง และปล่อยส่วนที่เหลือให้ถูกปฏิเสธ
ทดสอบจากเวิร์กโหลดทั่วไปในสาขา A ไปยังบริการจริงในสาขา B ยืนยันคำตอบ แล้วลองการทำงานที่ควรถูกห้ามต่อไป ทราฟฟิกที่อุปกรณ์ VPN สร้างขึ้นเองอาจใช้ที่อยู่ต้นทางอื่นและข้ามขั้นตอนการกำหนดเส้นทางใน LAN ดังนั้น ping ที่สำเร็จจากเราเตอร์จึงพิสูจน์ได้น้อยกว่าที่เห็น
ปิดท้ายด้วยการจดข้อเท็จจริงสี่ข้อ: คำนำหน้าที่แลกเปลี่ยนกัน ASN ที่ใช้ เส้นทางกลับใน LAN ของแต่ละฝ่าย และนโยบายที่อนุญาตบริการ หากขาดข้อใดข้อหนึ่ง การตั้งค่าจะทำงานได้จนถึงการเปลี่ยนแปลงครั้งแรก และหลังจากนั้นไม่มีใครอธิบายได้ว่าทำไม