VPN เชื่อมไซต์ AWS ไป Azure: เขียนเส้นทางขากลับก่อน
อุโมงค์ที่เชื่อมต่อระหว่างคลาวด์สองแห่งไม่ได้พิสูจน์อะไร จนกว่าแต่ละซับเน็ตเวิร์กโหลดจะกำหนดเส้นทางไปยังคำนำหน้าปลายทางไกล ทำตามแผนตามลำดับแล้วทดสอบบริการ
อุโมงค์จะขึ้นมา มักเป็นเช่นนั้น เพราะ IKE ต้องการเพียงข้อเสนอที่ตรงกันและที่อยู่เพียร์ที่เข้าถึงได้ สิ่งที่ล้มเหลวหลังจากนั้นคือเส้นทางขากลับ: เวิร์กโหลดใน AWS ส่งแพ็กเก็ตเข้าไปในอุโมงค์ แต่ฝั่ง Azure ไม่มีใครรู้วิธีตอบ 10.10.0.0/16 หรือเส้นทางของ Azure อยู่ในตารางที่ซับเน็ตของเวิร์กโหลดไม่ได้ใช้ เขียนแผนเส้นทางก่อนแตะคอนโซลใด ๆ แล้วอุโมงค์จะเป็นส่วนที่น่าสนใจน้อยที่สุดของงาน
ขั้นที่ 1: หยุดแผนที่อยู่ให้นิ่ง
ทำงานด้วยค่าที่เป็นรูปธรรม เวิร์กโหลดใน AWS อยู่ที่ 10.10.1.20 ภายใน 10.10.0.0/16 และต้องการ TCP 443 ไปยังบริการ Azure ที่ 10.20.1.30 ภายใน 10.20.0.0/16 ช่วงทั้งสองต้องไม่ทับซ้อนกัน และการทดสอบการยอมรับคือคู่บริการ ไม่ใช่อุโมงค์
เขียนข้อเท็จจริงสี่ข้อนั้นก่อนสิ่งอื่นใด เพราะทุกขั้นตอนถัดไปจะถูกตรวจสอบกับมัน
ขั้นที่ 2: ตั้งชื่อเกตเวย์ที่เป็นเจ้าของแต่ละปลาย
AWS Site-to-Site VPN สามารถสิ้นสุดที่เกตเวย์ส่วนตัวเสมือนหรือเกตเวย์ส่งต่อ และทั้งสองเป็นเจ้าของเส้นทางที่ต่างกัน Azure มี VPN Gateway ที่จัดการให้และแยกเป็นอุปกรณ์บน VM ที่ลูกค้าเดินระบบเอง บันทึกว่าคุณมีคู่ไหน เพราะฮอปถัดไปต่างกันในแต่ละการรวมกัน
สำหรับเกตเวย์ที่จัดการให้ อย่าคัดลอกเส้นทางที่ชี้ไปยังที่อยู่ของอุปกรณ์ส่วนตัวที่เดาขึ้นมา สำหรับอุปกรณ์ อย่าสมมติว่าการเผยแพร่เส้นทางในคลาวด์กำหนดค่าระบบปฏิบัติการของแขก เพราะมันไม่ได้ทำเช่นนั้น
ผิดตรงนี้จะได้แผนที่ดูสมบูรณ์และส่งแพ็กเก็ตไปยังที่อยู่ที่ไม่เคยตอบกลับ
ขั้นที่ 3: เขียนเส้นทางที่แต่ละเวิร์กโหลดใช้จริง
แต่ละขอบเขตด้านล่างคือการค้นหาแยกกัน และเส้นทางในหนึ่งในนั้นไม่ใช่เส้นทางของแพ็กเก็ต เติมตารางด้วยค่าของคุณเองก่อนอุโมงค์จะเริ่มทำงาน
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
ใน AWS ตารางเส้นทางของซับเน็ตเวิร์กโหลดเป็นของคุณที่ต้องอัปเดต แม้หลังจาก BGP หรืออุโมงค์จะแข็งแรงแล้ว ภาพรวมการกำหนดเส้นทาง ถือว่าเป็นส่วนหนึ่งของการเชื่อมต่อ ใน Azure ตารางเส้นทางที่ผู้ใช้กำหนดจะเชื่อมกับซับเน็ตไม่ใช่กับเครือข่ายเสมือน ดังนั้นตรวจสอบเส้นทางที่มีผลบน NIC ของเวิร์กโหลด ไม่ใช่ในบานหน้าต่าง VNet
เกตเวย์ Azure ที่จัดการให้สามารถเรียนรู้คำนำหน้าปลายทางไกลผ่านการเผยแพร่ของเกตเวย์ และ UDR สามารถแทนที่การตัดสินใจนั้นได้ เพิ่ม UDR เมื่อมีเหตุผล ไม่ใช่ตามสัญชาตญาณ หากเพิ่ม ให้ชี้ไปยังฮอปถัดไปที่เกตเวย์เผยแพร่สำหรับเส้นทาง VPN แทนการสร้างที่อยู่ของอุปกรณ์ขึ้นมา แล้วอ่านเส้นทางที่มีผลบน NIC อีกครั้ง เพราะการตัดสินใจเกิดขึ้นที่นั่นจริง
ขั้นที่ 4: ทำให้ขอบเขตสอดคล้องกัน
สำหรับ BGP เปรียบเทียบสิ่งที่แต่ละฝ่ายประกาศกับสิ่งที่อีกฝ่ายเรียนรู้จริง ทีละคำนำหน้า สำหรับการกำหนดเส้นทางแบบคงที่ เปรียบเทียบช่วงปลายทางไกลที่กำหนดไว้กับเส้นทางของเวิร์กโหลดที่เขียนในขั้นที่ 3
ความสัมพันธ์ IKE ที่ตกลงเรื่องการเข้ารหัสไม่ใช่หลักฐานว่าฝ่ายใดได้เรียนรู้ 10.10.0.0/16 หรือ 10.20.0.0/16 อุโมงค์สองเส้นอาจขึ้นอยู่ขณะที่ฝ่ายหนึ่งประกาศเพียง /24 แทน /16 ที่คุณวางแผนไว้ ตรวจสอบคำนำหน้าในตารางเส้นทาง ไม่ใช่ในสถานะอุโมงค์ ความไม่ตรงกันจะปรากฏภายหลังเป็นซับเน็ตที่ทำงานได้หนึ่งแห่งและอีกแห่งที่ไม่เคยตอบกลับ
ขั้นที่ 5: ทดสอบบริการจากต้นทางจริง
อนุญาตโฟลว์ที่ตั้งใจในกลุ่มความปลอดภัยและ ACL เครือข่ายของ AWS ใน NSG ของ Azure และในตัวกรองอุปกรณ์ใด ๆ บนเส้นทาง จากนั้นเปิดการเชื่อมต่อหนึ่งครั้งจาก 10.10.1.20 ไปยังที่อยู่และพอร์ตของบริการที่อนุมัติ และยืนยันว่าการตอบกลับมาถึงต้นทางเดียวกัน
ทั้งกลุ่มความปลอดภัยบนคลาวด์และ NSG ต่างเก็บสถานะ ดังนั้นแพ็กเก็ตขากลับที่ถูกปฏิเสธจึงเป็นอาการของการกำหนดเส้นทาง ไม่ใช่กฎที่คุณลืมเขียนย้อนกลับ
ping จากเกตเวย์ใด ๆ ไม่ตัดสินอะไร ICMP ไปยังที่อยู่เกตเวย์ฝึกเส้นทางระนาบควบคุม ไม่ใช่บริการ TCP ที่ถูกส่งต่อซึ่งเวิร์กโหลดต้องการ
การย้อนกลับและบันทึก
บันทึกเจ้าของเส้นทางข้างตัวระบุอุโมงค์ และเก็บตารางเส้นทางก่อนการเปลี่ยนแปลงไว้ หากต้องถอนการเปลี่ยนแปลง ให้ลบเส้นทางของเวิร์กโหลดก่อนรื้ออุโมงค์ เพื่อไม่ให้ซับเน็ตใดชี้ไปยังฮอปถัดไปที่ไม่มีอยู่แล้ว
จากนั้นการย้ายซับเน็ตหรือการเชื่อมต่อ spoke ในภายหลังจะมีที่เดียวที่กำหนดไว้ให้อัปเดต แทนที่จะเป็นอุโมงค์ที่ทำงานอยู่และแบกรับความผิดของเส้นทางที่มันไม่เคยเป็นเจ้าของ