AWS NAT เกตเวย์ใช้ IP ต้นทางใดเมื่อส่งไปยัง VPN

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

เริ่มที่หน้า NAT เกตเวย์ ไม่ใช่ที่รายการที่อนุญาต

หน้า NAT เกตเวย์บอกซับเน็ต ชนิด และ Elastic IP แก่คุณ และสามฟิลด์นั้นก็เพียงพอที่จะเริ่ม สิ่งที่มันไม่บอกคือเส้นทางที่แทรฟฟิกใช้ต่อจากนั้น ซึ่งมาจากตารางเส้นทางที่ผูกกับซับเน็ตของ NAT เกตเวย์

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

ติดตามการแปลงสองครั้ง

ทั้ง NAT เกตเวย์สาธารณะและส่วนตัวแปลงแหล่ง IPv4 ส่วนตัวของเวิร์กโหลดเป็นที่อยู่ IPv4 ส่วนตัวของ NAT เกตเวย์เอง การแปลงครั้งแรกเกิดขึ้นโดยไม่ขึ้นกับชนิด การแปลงครั้งที่สองคือสิ่งที่คนมักลืม: NAT เกตเวย์สาธารณะส่งแทรฟฟิกต่อให้เกตเวย์อินเทอร์เน็ต ซึ่งแมปที่อยู่ไปยัง Elastic IP ที่ผูกอยู่

workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> internet gateway -> Elastic IP 203.0.113.25
workload 10.20.1.5 -> NAT gateway 10.20.2.10 -> transit or virtual private gateway -> partner sees 10.20.2.10

บนเส้นทางส่วนตัวไม่มีเกตเวย์อินเทอร์เน็ตในห่วงโซ่ เมื่อแทรฟฟิกออกผ่านเกตเวย์ทรานสิตหรือเกตเวย์ส่วนตัวเสมือน คู่มือ NAT เกตเวย์ บันทึกที่อยู่ส่วนตัวของ NAT เกตเวย์เป็นแหล่งที่ฝั่งปลายทางได้รับ นั่นคือที่อยู่ที่พาร์ทเนอร์ควรอนุญาต ไม่ใช่ Elastic IP

เส้นทาง VPN มักแสดงที่อยู่ส่วนตัว

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

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

เมื่อการแปลงครั้งที่สองเปลี่ยนคำตอบ

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

หากการออกแบบของคุณใช้แมปปิงนั้น รายการที่อนุญาตต้องอธิบายแมปปิงสุดท้าย ไม่ใช่ที่อยู่ของ NAT เกตเวย์ ข้อควรระวังเดียวกันใช้กับเส้นทางความพร้อมใช้งาน: เมื่อมีที่อยู่เกตเวย์หลายรายการเข้าร่วม ชุดแหล่งที่คาดหวังคือยูเนียน ไม่ใช่ที่อยู่ตัวแทนเพียงรายการเดียว จดบันทึกว่าแต่ละที่อยู่เป็นการแปลงใด เพราะรายการที่ไม่มีที่มาไม่สามารถตรวจสอบย้อนหลังได้

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

เขียนสัญญาที่พาร์ทเนอร์ของคุณนำไปใช้ได้

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

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

จากนั้นตรวจสอบตารางเส้นทางทั้งสองอีกครั้งหลังการเปลี่ยนแปลงใด ๆ เพราะส่วนแนบใหม่หรือซับเน็ตที่เชื่อมโยงใหม่จะเขียนคำตอบใหม่โดยไม่ส่งเสียง