LAN เบื้องหลังเซสชัน AWS Client VPN หนึ่งเซสชัน: อะไรถูกส่งต่อ

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

การขยายเซสชัน Client VPN ไปยัง LAN คือบทบาทเกตเวย์ ไม่ใช่เซกเมนต์ Ethernet ที่ยืดเข้าไปในบริการที่มีการจัดการ

โฮสต์ทำงานแต่ LAN ไม่

อินเทอร์เฟซอุโมงค์บนเครื่อง Linux มีที่อยู่ภายใน CIDR ของไคลเอนต์ Client VPN และปลายทางได้ผลักเส้นทางสำหรับช่วง VPC คำขอที่ทำบนเครื่องนั้นเป็นทราฟฟิกที่สร้างขึ้นในเครื่อง: เลือกเส้นทาง ออกผ่านอุโมงค์ และได้รับคำตอบ เส้นทางนั้นไม่เคยแตะโค้ดส่งต่อ อินเทอร์เฟซ LAN หรือกฎไฟร์วอลล์ใดที่ควบคุมการผ่าน

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

ไม่ใช่ทุกไคลเอนต์จะเป็นเกตเวย์ได้

AWS ระบุว่าแอปเดสก์ท็อป Client VPN ไม่รองรับการส่งต่อ IP และไคลเอนต์อื่นอาจรองรับ ข้อจำกัดนั้นกำหนดสถาปัตยกรรมก่อนที่จะพิมพ์คำสั่งใด ๆ หากไคลเอนต์เดียวที่ใช้ได้คือแอปเดสก์ท็อปอย่างเป็นทางการ เกตเวย์ Linux ที่ส่งต่อให้ LAN ไม่ใช่การกำหนดค่าที่คุณทำเสร็จได้ และ masquerading เท่าไรก็ไม่เปลี่ยน

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

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

ส่ง LAN เข้าอุโมงค์และแปลมัน

เมื่อมีไคลเอนต์ที่รองรับอยู่ ส่วนที่เหลือคืองานเกตเวย์ปกติ อุปกรณ์ LAN ต้องการเส้นทางสำหรับช่วง VPC ที่ชี้ไปยังโฮสต์ Linux และโฮสต์ต้องการการส่งต่อที่เปิดอยู่ หากต้องการให้ VPC มองทราฟฟิกเป็นไคลเอนต์ที่เชื่อมต่อไม่ใช่ที่อยู่ LAN ตามอำเภอใจ ให้แปลต้นทางตอนออก

LAN: 10.24.11.0/24
Linux LAN gateway: 10.24.11.15
VPN interface: tun0
Target VPC range: 10.2.0.0/16

iptables -t nat -A POSTROUTING -s 10.24.11.0/24 -d 10.2.0.0/16 -o tun0 -j MASQUERADE

จำกัดกฎไว้ที่อินเทอร์เฟซอุโมงค์และช่วง VPC ตามข้างต้น แทนที่จะ masquerade ทุกสิ่งที่โฮสต์ส่งต่อ กฎที่แคบกว่าคิดตามได้ง่ายกว่า และไม่เปลี่ยนทราฟฟิกที่ควรคงที่อยู่ต้นทางเดิมอย่างเงียบ ๆ

ปล่อยให้เส้นทาง LAN มาถึงโดยอัตโนมัติหากทำได้: ตัวเลือก DHCP การประกาศของเราเตอร์ หรือเส้นทางแบบคงที่ที่ผลักโดยสิ่งที่จัดการ LAN เส้นทางที่มีอยู่เพียงเครื่องทดสอบเครื่องเดียวจะทำให้การออกแบบดูพังในทันทีที่คนอื่นลอง

คำตอบก็ต้องการเส้นทาง

เมื่อคำขอไปถึง VPC คำตอบต้องกลับมาผ่านสถานะการแปลเดียวกันและพบเส้นทาง LAN บนเกตเวย์ ส่วนนั้นมักทำงานเมื่อกฎ masquerade อยู่ในที่ เพราะการแมปอาศัยอยู่บนโฮสต์ที่ทำ มันพังเมื่อฝั่ง VPC มีเส้นทางที่ส่งคำตอบไปที่อื่น และนั่นคือเหตุผลที่ทั้งเส้นทาง CIDR ของไคลเอนต์และการเชื่อมโยงซับเน็ตบนปลายทางสำคัญ

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

จำไว้ว่าปลายทางเป็นบริการที่มีการจัดการ ไม่มีไฟล์กำหนดค่าเซิร์ฟเวอร์ให้แก้ไขและไม่มีคำสั่ง client-config ให้เพิ่ม ดังนั้นคำแนะนำที่เขียนสำหรับเซิร์ฟเวอร์ OpenVPN ที่จัดการเองซึ่งมีเส้นทางซับเน็ตไคลเอนต์แบบกำหนดเองจึงไม่ถ่ายโอน ใน AWS คันโยกคือการเชื่อมโยงซับเน็ต กฎการอนุญาต และตารางเส้นทางของ VPC

อัตลักษณ์ร่วมคือส่วนที่นโยบายต้องตอบ

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

นั่นอาจยอมรับได้ หรืออาจเป็นเหตุผลที่การออกแบบถูกปฏิเสธ ขึ้นอยู่กับสิ่งที่ทรัพยากร VPC สันนิษฐานเกี่ยวกับผู้ที่เรียกเข้ามา อัตลักษณ์ร่วมที่เข้ากับรูปแบบการอนุญาตก็ใช้ได้ ส่วนที่เปลี่ยนเซสชันที่ตรวจสอบสิทธิ์แล้วหนึ่งเซสชันเป็นการเข้าถึงทั้ง LAN อย่างเงียบ ๆ คือข้อค้นพบที่รอการเขียน

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

ตัดสินใจเรื่องไคลเอนต์ เส้นทาง การแปล และเรื่องราวอัตลักษณ์ตามลำดับนั้น แต่ละอย่างจำกัดอย่างถัดไป และลำดับนี้อธิบายว่าทำไมโฮสต์จึงทำงานในขณะที่ LAN ไม่