AWS Client VPN หรือ bastion สำหรับเข้าถึง VPC ที่มี peering

endpoint เดียวของ Client VPN เข้าถึง VPC ที่มี peering กับ VPC ที่เชื่อมโยงได้ และคุณไม่จำเป็นต้องมี bastion เพื่อทำให้ถูกต้องตามกฎ สิ่งที่คุ้มค่าที่จะเลือกคือจุดที่ทราฟฟิกเปลี่ยนมือ: เส้นทาง endpoint ที่ลงในซับเน็ตของ association และข้ามการเชื่อมต่อ peering หรือโฮสต์ใน VPC ที่มี peering ซึ่งสิ้นสุดเซสชัน ทั้งสองเส้นทางทำงานและล้มเหลวคนละจุด ดังนั้นการตัดสินใจจึงเกี่ยวกับความเป็นเจ้าของและการตรวจสอบ ไม่ใช่เกี่ยวกับสิ่งที่ AWS อนุญาต นี่คือวิธีที่ฉันเลือกระหว่างสองเส้นทาง และสี่รายการที่ทำให้เส้นทางแบบกำหนดเส้นทางทำงานได้

สองเส้นทาง endpoint เดียว เจ้าของต่างกัน

บนเส้นทางที่กำหนดเส้นทาง ทราฟฟิกของไคลเอนต์ไปถึง endpoint ถูกแปลเป็นที่อยู่ของอินเทอร์เฟซเครือข่าย Client VPN ในซับเน็ตของ association และออกจากซับเน็ตนั้นผ่านการเชื่อมต่อ peering จาก A ไป B VPC B ไม่ได้สิ้นสุดเซสชัน VPN ใด ๆ มันเห็นทราฟฟิกปกติจาก VPC A ดังนั้นเส้นทางขากลับจึงชี้ไปที่ VPC A ไม่ใช่พูลไคลเอนต์

บนเส้นทาง bastion ไคลเอนต์ไปถึงโฮสต์ก่อน bastion ใน A ยังปล่อยให้ฮอปสุดท้ายข้ามการเชื่อมต่อ peering ดังนั้นคุณยังคงงาน peering ไว้และเพิ่มเซสชันหนึ่งรายการ bastion ใน B ก็ต้องการเส้นทางจากไคลเอนต์เช่นกัน และเมื่อเส้นทางนั้นเป็นเส้นทาง endpoint เดียวกัน คุณจะได้การออกแบบแบบกำหนดเส้นทางบวกหนึ่งฮอป bastion ลดงานได้เฉพาะเมื่อมันมีอยู่แล้ว ได้รับการอนุมัติแล้ว และสิ่งที่อยู่ข้างหลังต้องการขอบเขตเซสชันไม่ใช่ขอบเขตเครือข่าย

สี่รายการทำให้เส้นทางที่กำหนดเส้นทางทำงานได้

AWS จัดทำเอกสารสถานการณ์นี้บนหน้า Client VPN how-it-works และในทางปฏิบัติเหลือเพียงสี่รายการที่ทีมสองหรือสามทีมเป็นเจ้าของ ช่วงเป็นเพียงตัวอย่าง ช่วง peering ต้องไม่ซ้ำกัน และช่วงขากลับต้องตรงกับแผนของคุณ

เส้นทางและสิทธิ์เป็นตัวควบคุมที่แยกกัน เส้นทาง endpoint ที่ถูกต้องโดยไม่มีกฎการอนุญาตที่ตรงกันไม่ให้อะไรกับไคลเอนต์ กฎการอนุญาตสำหรับปลายทางที่ endpoint กำหนดเส้นทางไม่ได้ให้หลุมดำกับมัน ทั้งสองต้องระบุช่วงเดียวกัน

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

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

กลุ่มความปลอดภัยและเมตรสุดท้ายของสิทธิ์

การกำหนดเส้นทางนำแพ็กเก็ตเข้า B แต่ B ยังคงตัดสินใจ สำหรับการเชื่อมต่อ peering ที่ใช้งานอยู่ในภูมิภาคเดียวกัน กลุ่มความปลอดภัยใน B สามารถอ้างอิงกลุ่มที่ใช้กับการเชื่อมโยง Client VPN ซึ่งทำให้กฎแคบและทนต่อการเปลี่ยนแปลงที่อยู่ ในกรณีที่การอ้างอิงกลุ่มทำไม่ได้ ให้อนุญาตช่วงของซับเน็ต association อย่างชัดเจนแทนการขยายเป็น 0.0.0.0/0 ซึ่งเปลี่ยนข้อผิดพลาดในการกำหนดเส้นทางเป็นหมดเวลาที่อธิบายไม่ได้

จากนั้นตรวจสอบสิ่งที่การกำหนดเส้นทางไม่เคยแตะต้อง: ACL เครือข่ายบนซับเน็ตทั้งสอง รายการที่อนุญาตหรือผู้ชมโทเค็นของแอปพลิเคชัน และ DNS peering ไม่คัดลอกโซนที่โฮสต์แบบส่วนตัว ดังนั้นแล็ปท็อปอาจมีเส้นทางที่ใช้งานได้ไปยังที่อยู่ที่ไม่สามารถแก้ไขได้ และการเชื่อมต่อ peering ไม่เพิ่มความเชื่อถือให้ใบรับรอง ชี้ endpoint ไปที่ตัวแก้ไขที่ตอบให้ B แล้วยืนยันว่าชื่อส่วนตัวและใบรับรองตรงกัน

เมื่อ bastion คือคำตอบที่ซื่อตรง

ฉันเก็บตัวกระตุ้นสามอย่างสำหรับการเลือก bastion อย่างจงใจ VPC ที่มี peering เป็นของทีมที่จะไม่เพิ่มเส้นทางขากลับสำหรับช่วงของคุณหรือจะไม่ยอมรับการอ้างอิงกลุ่ม หรือการเข้าถึงต้องได้รับการอนุมัติหรือบันทึกต่อเซสชันและแอปพลิเคชันไม่สามารถรับภาระนั้นได้เอง หรือฮอปสุดท้ายต้องอยู่ภายใน B เพราะบริการแก้ไขได้เฉพาะที่นั่นและตัวตน TLS ของมันถูกปักหมุดกับชื่อภายใน

ไม่มีสิ่งใดในนี้เป็นการหลีกเลี่ยงข้อเท็จจริงที่ว่า peering ไม่ใช่ทรานซิทีฟ ความไม่เป็นทรานซิทีฟจำกัดสิ่งที่ทรัพยากรใน B ทำได้ พวกมันไม่สามารถใช้ A เป็นทรานซิตไปยัง VPC ที่สามที่ A มี peering ด้วย สิ่งนี้ไม่เคยหมายความว่าผู้ใช้ VPN ไม่สามารถเข้าถึง VPC ที่มี peering โดยตรง และ bastion ที่สร้างขึ้นเพื่อหลีกเลี่ยงการตีความผิดนั้นคือโฮสต์ที่ถูกแพตช์โดยไม่มีเหตุผล

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

Transit Gateway และหลาย association เปลี่ยนเลขคณิต

หาก endpoint เชื่อมต่อโดยตรงกับ Transit Gateway แทนที่จะเป็นซับเน็ต โมเดลจะเปลี่ยน ไคลเอนต์ไม่ถูกแปลเป็นที่อยู่ของอินเทอร์เฟซในซับเน็ต association อีกต่อไป และตารางเส้นทางของเกตเวย์ต้องพาช่วงไคลเอนต์บวกการเชื่อมต่อที่นำไปสู่ VPC ที่มี peering นั่นสะอาดกว่าในระดับขนาด แต่งานย้ายจากสี่รายการไปยังตารางเส้นทางของเกตเวย์

หลาย association ทวีคูณการตรวจสอบ เส้นทาง endpoint เป็นของ endpoint แต่ทุกซับเน็ต association ต้องการตารางเส้นทางที่มีฮอปถัดไป peering จริง เซสชันอาจสำเร็จผ่าน association หนึ่งในขณะที่อีกอันไม่มีเส้นทางขากลับ ดังนั้นทดสอบแต่ละอัน

ลำดับการตรวจสอบที่ค้นหาความเสียหายได้เร็ว

เรียกใช้ตามลำดับ แต่ละขั้นตอนอาจผ่านในขณะที่ขั้นตอนถัดไปล้มเหลว และหมดเวลาของไคลเอนต์แทบไม่เคยบอกว่าอันไหนพัง

1. แก้ไขชื่อแอปพลิเคชันจากไคลเอนต์และตรวจสอบว่าที่อยู่อยู่ในช่วง peering
2. เชื่อมต่อ แล้วอ่านบันทึกการเชื่อมต่อของ endpoint สำหรับ association ที่สิ้นสุดเซสชัน
3. บนซับเน็ต association นั้น ยืนยันว่าตารางเส้นทางชี้ช่วง peering ไปยังการเชื่อมต่อ peering ที่ใช้งานอยู่
4. บนซับเน็ตทรัพยากรใน B ยืนยันรายการขากลับสำหรับช่วงอินเทอร์เฟซและกฎกลุ่มที่ตรงกัน
5. ทดสอบการดำเนินการที่ได้รับอนุญาตหนึ่งรายการและทรัพยากรหนึ่งรายการที่ต้องไม่สามารถเข้าถึงได้ รายการที่สองจับเศษของการดีบัก
6. เชื่อมต่อใหม่หลังการเปลี่ยนแปลงเส้นทาง split-tunnel ทุกครั้ง เพราะอุโมงค์ที่ทำงานอยู่จะไม่รับชุดเส้นทางใหม่

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

หากไม่มีตัวกระตุ้นทั้งสามข้อใช้ ให้ทำเส้นทางที่กำหนดเส้นทางให้เสร็จและบันทึกสี่รายการนั้น หากข้อใดข้อหนึ่งใช้ ให้เก็บ bastion ไว้เฉพาะขอบเขตนั้นและปล่อยเส้นทาง endpoint ไว้สำหรับบริการที่ไม่ต้องการเซสชันข้างหน้า