อุโมงค์เต็มรูปแบบของ Access Server บน EC2: ทำไมช่องทำเครื่องหมายช่องเดียวจึงไม่พอ

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

การตรวจสอบควบคุมอะไรจริง

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

ตรวจสอบค่าปัจจุบันด้วย aws ec2 describe-instance-attribute --instance-id i-0123456789abcdef0 --attribute sourceDestCheck ก่อนเปลี่ยนแปลงสิ่งใด หากคุณเปลี่ยนในคอนโซล ให้เปลี่ยนเพราะอินสแตนซ์ส่งต่อให้ผู้อื่น ไม่ใช่เพราะไคลเอนต์เข้าถึงอินเทอร์เน็ตไม่ได้

นโยบายเส้นทางของไคลเอนต์เป็นของ Access Server

ใน Access Server 3 ให้เปิด Access Controls แล้วหาส่วน Internet Access and DNS ตัวเลือก Internet Gateway เสนออุโมงค์เต็มหรืออุโมงค์แยก อุโมงค์เต็มบอกไคลเอนต์ให้กำหนดเส้นทางทราฟฟิกเริ่มต้นเข้าไปใน VPN อุโมงค์แยกปล่อยทราฟฟิกอินเทอร์เน็ตไว้บนเส้นทางท้องถิ่นของไคลเอนต์ บันทึกและใช้งานผ่านขั้นตอนการทำงานของผลิตภัณฑ์ แล้วเชื่อมต่อไคลเอนต์ทดสอบใหม่ เพราะนโยบายถูกส่งมอบในเวลาที่เชื่อมต่อ

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

ติดตามแพ็กเก็ตหลังอุโมงค์

เมื่อไคลเอนต์ส่งทราฟฟิกอินเทอร์เน็ตเข้าไปในอุโมงค์ เซิร์ฟเวอร์ต้องส่งต่อและโดยปกติต้องแปลมัน Access Server จัดการกฎ NAT และเส้นทางของตัวเอง ดังนั้นจงอ่านการกำหนดค่าที่มีผลจริงแทนการเพิ่มกฎ Community OpenVPN ลงในไฟล์ที่สร้างขึ้น กฎที่ไม่ได้จัดการจะถูกเขียนทับหรือขัดแย้งในการอัปเดตผลิตภัณฑ์ครั้งถัดไป sudo iptables -t nat -L -n -v หรือสิ่งที่เทียบเท่าใน nftables แสดงให้เห็นว่าอะไรกำลังถูกแปลจริง

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

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

แยกทางออก IP กับ DNS ออกจากกัน

ทดสอบที่อยู่แบบตัวอักษรก่อน แล้วจึงทดสอบชื่อ จากแอปไคลเอนต์เดียวกัน หาก curl -4 https://checkip.amazonaws.com คืนที่อยู่สาธารณะแต่ชื่อโฮสต์ล้มเหลว อุโมงค์และเส้นทาง NAT ทำงาน และปัญหา คือ DNS: ตัวแก้ไขที่ถูกส่งไป สถานะตัวแก้ไขของไคลเอนต์ หรือกลุ่มความปลอดภัยที่บล็อกตัวแก้ไข การตั้งค่า DNS ของ Access Server อยู่ในพื้นที่ Internet Access เดียวกัน แต่เดินทางผ่านเส้นทางโค้ดที่ต่างกัน

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

อย่าให้ช่องทำเครื่องหมายช่องเดียวปิดการสอบสวน

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

สุดท้าย ทดสอบสถานะที่ตัดการเชื่อมต่อ การเลือกอุโมงค์เต็มอธิบายนโยบายเส้นทางขณะเชื่อมต่อ ไม่ใช่ว่าเกิดอะไรขึ้นเมื่ออุโมงค์ล่ม หากข้อกำหนดคือไม่มีทราฟฟิกรั่วออกนอก VPN นั่นคือคำถามเรื่อง kill-switch และไฟร์วอลล์ และต้องมีการทดสอบของตัวเองแทนการอนุมานจากตารางเส้นทาง