CIDR ภายในและระยะไกลใน AWS VPN: ฝั่งไหนคือฝั่งไหน

คุณเปิดตัวเลือก Site-to-Site VPN เห็นช่อง CIDR สองช่องที่ติดป้ายว่าภายในและระยะไกล แล้วเอื้อมไปยังที่อยู่ที่คุณคิดว่าเป็นภายใน: VPC นั่นตรงข้ามกับสิ่งที่ API หมายถึง ในตัวเลือกการเชื่อมต่อ LocalIpv4NetworkCidr ระบุฝั่งเกตเวย์ของลูกค้า และ RemoteIpv4NetworkCidr ระบุฝั่ง AWS เพราะการเชื่อมต่อสร้างจากเกตเวย์ของลูกค้า คอนโซลไม่เคยพูดเรื่องนี้เสียงดัง และไม่มีอะไรปฏิเสธการสลับที่ดูสมเหตุสมผล

เริ่มที่การเรียก API ไม่ใช่ที่ป้ายในคอนโซล

อ่านเอกสารอ้างอิงตัวเลือกการเชื่อมต่อหนึ่งครั้งให้จบ แล้วสังเกตว่าทุกตัวเลือกเขียนจากมุมมองของเกตเวย์ลูกค้า นั่นไม่ใช่ความบังเอิญของการตั้งชื่อ อุโมงค์ถูกอธิบายตามที่อุปกรณ์ซึ่งสิ้นสุดมันฝั่งคุณมองเห็น ดังนั้นภายในหมายถึงเครือข่ายหลังเกตเวย์ของคุณ และระยะไกลหมายถึงเครือข่ายหลังเกตเวย์ AWS ทั้งช่อง IPv4 และ IPv6 ใช้กฎเดียวกัน

เขียนป้ายสองอันลงบนกระดาษโน้ตก่อนพิมพ์อะไรทั้งสิ้น: ฝั่งลูกค้า ฝั่ง AWS จากนั้นจับคู่ที่อยู่ของคุณเข้ากับป้ายเหล่านั้น

ตัวอย่างที่ทำครบพร้อมบทบาท

สมมติคำนำหน้าภายในคือ 10.20.0.0/16 และคำนำหน้า VPC คือ 10.60.0.0/16 ตัวเลือกอ่านได้ตรงตามที่บทบาทบอก โดยช่วงภายในอยู่ในช่องภายใน:

{
  "LocalIpv4NetworkCidr": "10.20.0.0/16",
  "RemoteIpv4NetworkCidr": "10.60.0.0/16"
}

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

ทำแบบฝึกหัดซ้ำบนกระดาษด้วยศัพท์ของอุปกรณ์คู่ พร้อม CIDR ทั้งสองและป้ายทั้งสอง ก่อนแตะอุปกรณ์ใด ๆ

ค่าเริ่มต้นไม่ใช่การออกแบบ

เอกสารอ้างอิงเดียวกันระบุ 0.0.0.0/0 เป็นค่าเริ่มต้นสำหรับทั้งสองช่อง IPv4 พร้อมค่าที่คล้ายกันสำหรับ IPv6 การเห็นค่าเหล่านั้นในการเชื่อมต่อที่มีอยู่บอกว่าช่องนั้นไม่เคยถูกจำกัดให้แคบลง ไม่ได้หมายความว่าตั้งค่าทางออกอินเทอร์เน็ตแล้ว การกระจายเส้นทาง ตารางเส้นทางของซับเน็ต และการควบคุมความปลอดภัยยังคงตัดสินว่าทราฟฟิกใดผ่านได้จริง ค่า CIDR เพียงอธิบายว่าอุโมงค์ยินดีเลือกช่วงใด

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

อุปกรณ์คู่ใช้มุมมองอีกด้าน

เมื่อฝั่ง AWS ชัดเจนแล้ว การกำหนดค่าของคู่คือที่ที่ความสับสนที่เหลืออยู่มากที่สุด อุปกรณ์ที่ถามหาเครือข่ายภายในและเครือข่ายระยะไกลอธิบายอินเทอร์เฟซของตัวเองว่าภายใน ดังนั้นช่วง VPC ของคุณไปอยู่ในช่องระยะไกลของมัน และช่วงภายในของคุณไปอยู่ในช่องภายในของมัน ถ้าแทนที่จะถามหาตัวเลือกทราฟฟิกเป็นคู่ คุณก็เขียนทั้งสองทิศทางอย่างชัดเจน และป้ายสำคัญน้อยกว่าการจับคู่

อ่านคำช่วยเหลือของช่องบนอุปกรณ์ ไม่ใช่ชื่อช่อง ผู้ผลิตใช้สองคำเดิมกับสามแนวคิดที่ต่างกัน

จากนั้นตรวจสอบสถานะอุโมงค์ทั้งสองเฟส เพราะตัวเลือกที่ไม่ตรงกันมักปรากฏเป็นความล้มเหลวของเฟสที่สอง ขณะที่เฟสแรกยังคงตั้งอยู่เงียบ ๆ

แก้ไขตัวเลือกเหมือนการเปลี่ยนแปลง ไม่ใช่เหมือนเอกสาร

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

หลังการเปลี่ยนแปลง ให้ตรวจสอบจากฝั่ง AWS และจากอุปกรณ์คู่: แหล่งในแต่ละช่วงไปถึงปลายทางในอีกช่วงหนึ่ง ทั้งสองทิศทาง ping เดียวจากด้านหนึ่งพิสูจน์ได้เพียงตัวเลือกเดียว

จากนั้นอัปเดตเอกสารการเชื่อมต่อโดยเขียนบทบาทให้ชัดเจน เพื่อให้คนถัดไปไม่ต้องค้นพบใหม่ว่าภายในหมายถึงฝั่งของคุณ