Anypoint VPN หรือ NAT ใน Transit Gateway: การแปลเกิดขึ้นที่ใด
Anypoint VPN ไม่ได้แปลที่อยู่ด้วยตัวเอง ตัดสินใจเลือกระหว่างการออกแบบ PAT บนไฟร์วอลล์ แผนที่พรีฟิกซ์ของ AWS หรือการเชื่อมต่ออื่นก่อนสัญญาเรื่อง NAT
ข้อกำหนดเรื่อง NAT ไม่ใช่ข้อกำหนดจนกว่าจะระบุที่อยู่ที่เปลี่ยนและองค์ประกอบที่ได้รับอนุญาตให้เปลี่ยน ในการเชื่อมต่อ MuleSoft การตัดสินใจนั้นมีข้อมูลเข้าสามอย่าง: แบ็กเอนด์ต้องการการแปลพอร์ตแบบหลายต่อหนึ่งหรือนามแฝงพรีฟิกซ์แบบหนึ่งต่อหนึ่ง การเชื่อมต่อ AWS ที่คุณเป็นเจ้าของจริงสามารถทำการแมปนั้นได้หรือไม่ และเส้นทางทั้งหมดยังอยู่ในชุดผสมที่ผู้จำหน่ายรองรับหรือไม่ หากผิดพลาดคุณจะสร้างห้องปฏิบัติการที่ทำงานได้แต่ตกในการตรวจสอบ
จุดคงที่เพียงจุดเดียวคือ Anypoint VPN เองไม่ใช่อุปกรณ์แปล เอกสาร CloudHub 2.0 ระบุว่า NAT ไม่ได้รับการรองรับที่นั่น ดังนั้นการออกแบบใดที่ถือว่าอุโมงค์จะซ่อนที่อยู่ของผู้ปฏิบัติงานของคุณก็เสียอยู่แล้ว
กำหนดว่าการแปลต้องทำอะไร
หากผู้ปฏิบัติงานแอปพลิเคชันจำนวนมากต้องปรากฏต่อแบ็กเอนด์เป็นที่อยู่เดียว ข้อกำหนดคือการแปลต้นทางแบบใช้ร่วมกัน โดยปกติคือ SNAT หรือ PAT ที่รักษาสถานะบนไฟร์วอลล์ที่คุณควบคุม องค์ประกอบนั้นต้องอยู่บนเส้นทางที่ได้รับอนุมัติ รักษาสถานะตลอดอายุของโฟลว์ และเห็นทราฟฟิกขากลับของทุกการเชื่อมต่อที่เขียนใหม่ การสูญเสียสถานะกลางเซสชันไม่ได้ทำให้การเชื่อมต่อแย่ลง แต่ทำให้สิ้นสุดลง คู่ไฟร์วอลล์ที่ปฏิเสธการแชร์สถานะการแปลจะทิ้งทุกเซสชันที่ไปลงบนสมาชิกสำรองหลังการสลับ ขนาดองค์ประกอบนั้นให้พอสำหรับโฟลว์พร้อมกัน ไม่ใช่สำหรับปริมาณงาน
หากกลับกันสองเครือข่ายทับซ้อนกันและแต่ละโฮสต์ต้องการนามแฝงที่แตกต่าง ข้อกำหนดคือแผนที่อยู่แบบหนึ่งต่อหนึ่งที่มีพรีฟิกซ์ที่แมปอย่างชัดเจน เส้นทางที่สอดคล้อง และการแก้ชื่อที่สอดคล้องกับการแมป การซ่อนผู้ปฏิบัติงานทุกคนไว้หลังที่อยู่เดียวไม่ใช่เวอร์ชันที่ถูกกว่าของสิ่งนั้น และการสลับสิ่งหนึ่งกับอีกสิ่งในการตรวจสอบการออกแบบคือวิธีที่โครงการสูญเสียไตรมาส
บันทึกการตัดสินใจเป็นถ้อยคำที่ชัดเจนก่อนเลือกผลิตภัณฑ์: ต้นทางเดิม ปลายทางเดิม ค่าที่แปลแล้ว ทิศทางของการเริ่มต้น เจ้าของตัวแปล และเส้นทางตอบกลับที่คาดไว้ เพิ่มข้อมูลอัตลักษณ์ที่บันทึกของแบ็กเอนด์จะเก็บไว้ เพราะการออกแบบที่ซ่อนต้นทางทั้งหมดก็ทำลายการตรวจสอบต่อไคลเอนต์ด้วย
ตรวจสอบว่า AWS ทำการแมปให้คุณได้หรือไม่
AWS เอกสาร NAT แบบหนึ่งต่อหนึ่งที่มีการจัดการบนการเชื่อมต่อ Transit Gateway และ Cloud WAN ซึ่งประกาศเมื่อปลายเดือนตุลาคม 2026 ดังนั้นข้อกล่าวอ้างเดิมที่ว่าทรานซิตเกตเวย์ไม่สามารถแปลได้เลยจึงล้าสมัย เอกสาร Transit Gateway NAT อธิบายการแมปพรีฟิกซ์ IPv4 แบบไม่มีสถานะ: พรีฟิกซ์ต้นทางและที่แปลแล้วคงความยาวเท่ากัน และบิตโฮสต์กับพอร์ตขนส่งยังคงอยู่หลังการแปล อ่านทิศทางขาเข้าและขาออกเป็นการตัดสินใจออกแบบแยกกัน เพราะกำหนดค่าแยกกันและอันหนึ่งอาจพร้อมในขณะที่อีกอันไม่พร้อม ไม่มีสิ่งใดในคำอธิบายนั้นบ่งบอกถึงสถานะต่อโฟลว์ ดังนั้นอย่าคาดว่าการแมปจะติดตามการเชื่อมต่อให้คุณ
นั่นหมายความว่า 10.80.0.0/16 ที่แมปไปยัง 172.28.0.0/16 จะเปลี่ยน 10.80.10.23 เป็น 172.28.10.23 ไม่ได้ย่อ /16 ให้เป็นที่อยู่เดียว และไม่ได้แทนข้อกำหนด PAT นอกจากนี้ยังครอบคลุมประเภทการเชื่อมต่อที่เลือก รวมถึง VPC และ Site-to-Site VPN แต่ไม่ใช่การเชื่อมต่อ Client VPN และการกำหนดค่าอยู่กับเจ้าของทรานซิตเกตเวย์ ไม่ใช่ฝั่ง Anypoint
มองคุณลักษณะนี้เป็นจุดควบคุมที่เป็นไปได้อีกจุดหนึ่ง ไม่ใช่หลักฐานว่าการติดตั้งของคุณใช้ได้ CloudHub 2.0 เอกสารการเชื่อมต่อพื้นที่ส่วนตัวไปยังทรานซิตเกตเวย์ในบัญชี AWS ของลูกค้าเอง พร้อมเงื่อนไขระดับภูมิภาคและเงื่อนไขสิทธิ ดังนั้นยืนยันประเภทการเชื่อมต่อจริง เจ้าของ และจุดยืนการสนับสนุนของผู้จำหน่ายก่อนออกแบบรอบตัวเลือกใหม่
เก็บเส้นทางไว้ในขอบเขตที่รองรับ
สำหรับตัวแปลบนไฟร์วอลล์ ใช้โมเดล VPN การแปล และการกำหนดเส้นทางที่รองรับของผลิตภัณฑ์นั้นแทนการแปะกฎ NAT ทั่วไปลงในอุโมงค์ที่ทำงานได้ คำตอบของแบ็กเอนด์ต้องกลับมาผ่านองค์ประกอบการแปลเดียวกัน และอุโมงค์ขาออกที่แข็งแรงไม่ได้บอกอะไรเกี่ยวกับเส้นทางขากลับนั้น
สำหรับเส้นทางทรานซิตเกตเวย์ ให้สำรวจรายการการเชื่อมต่อพื้นที่ส่วนตัว ตารางเส้นทางที่เกี่ยวข้อง การเชื่อมต่อในองค์กร และส่วนที่ลูกค้าสามารถกำหนดค่าได้จริง นี่คือสถาปัตยกรรมการเชื่อมต่อที่แตกต่าง ไม่ใช่ช่องทำเครื่องหมาย NAT ที่ขันเข้ากับการเชื่อมต่อ Anypoint VPN ที่มีอยู่ และขอบเขตการสนับสนุนก็เคลื่อนตามไปด้วย
เปรียบเทียบสามตัวเลือกในตารางเดียว
ทีมส่วนใหญ่ต้องตอบเพียงสองคำถาม: หลายต่อหนึ่งหรือหนึ่งต่อหนึ่ง และใครเป็นเจ้าของการเชื่อมต่อ ตารางด้านล่างเปลี่ยนคำตอบเหล่านั้นเป็นตัวเลือกเริ่มต้น
| Requirement | Starting option | What breaks it |
|---|---|---|
| Many workers, one backend address | Stateful PAT on your firewall | Asymmetric return path, expired state |
| Overlapping /16s, one-to-one | AWS prefix mapping on a supported attachment | Client VPN attachment, no explicit config |
| Per-client audit must survive | Keep original sources, translate downstream | Any many-to-one hiding of sources |
อ่านคอลัมน์ที่สามเป็นคำถามของการตรวจสอบ ไม่ใช่ความคิดภายหลัง แผนที่พรีฟิกซ์ที่ได้รับอนุญาตบนกระดาษแต่กำหนดค่าบนการเชื่อมต่อที่คุณไม่ได้เป็นเจ้าของยังคงเป็นโครงการที่ติดขัด และกฎ PAT ที่ปล่อยทราฟฟิกผ่านแต่ทำลายการบันทึกต่อไคลเอนต์ก็ตกในการตรวจสอบที่ตามมา
ตรวจสอบการแมปก่อนสัญญา
ส่งการดำเนินการแอปพลิเคชันใหม่หนึ่งครั้งผ่านเส้นทางและยืนยันคำตอบ ไม่ใช่แค่คำขอ ถามเจ้าของแบ็กเอนด์ว่าบันทึกของพวกเขาบันทึกที่อยู่ต้นทางใด ตรวจสอบว่าการจัดการตระกูลที่อยู่ตรงกับแผนในทั้งสองทิศทาง และยืนยันว่าเส้นทางที่ควรถูกปฏิเสธยังคงถูกปฏิเสธ การเชื่อมต่อเก่าไม่ได้พิสูจน์อะไรเกี่ยวกับการแมปที่คุณเพิ่งเปลี่ยน
แยกการพิสูจน์ตัวตนของแบ็กเอนด์ออกจากที่อยู่ที่แปลแล้วซึ่งทำให้รายการที่อนุญาตของมันพอใจ เพราะการแมปคืองานท่อประปาเครือข่าย ไม่ใช่การตัดสินใจควบคุมการเข้าถึง ในช่วงเวลาที่การรีเซ็ตรหัสผ่านขึ้นกับพรีฟิกซ์ NAT การเปลี่ยนช่วงในอนาคตทุกครั้งจะกลายเป็นการหยุดให้บริการ
ก่อนอนุมัติ ให้เขียนคำตอบสามข้อ: ประเภทของการแปล เจ้าของตัวแปล และการเชื่อมต่อหรือเส้นทางผลิตภัณฑ์ที่รองรับซึ่งรองรับมัน ถ้าข้อใดยังเป็นการเดา การออกแบบยังไม่พร้อมสำหรับหน้าต่างการเปลี่ยนแปลง