การเข้าถึงเป็นช่วง ๆ บน AWS Client VPN: ตรวจสอบทุกซับเน็ตที่เชื่อมโยง

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

เริ่มที่ปลายทางและแสดงรายการการเชื่อมโยง

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

หากปลายทางแสดงการเชื่อมโยงเดียว ทฤษฎีนี้ผิดและไคลเอนต์เป็นผู้ต้องสงสัยที่ดีกว่า

เทียบตารางเส้นทางของปลายทางกับการเชื่อมโยงทุกรายการ

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

เมื่อคุณทำตารางทั้งสองชั้นแล้ว ความล้มเหลวก็ยากที่จะมองข้าม

แถวที่สองคือบั๊กทั้งหมดในตั๋วส่วนใหญ่ เส้นทางของปลายทางมีอยู่ จึงไม่มีใครดูต่อไป และแพ็กเก็ตตายในอีกหนึ่งฮอปถัดมาภายใน VPC

ตามแต่ละซับเน็ตไปยังตารางเส้นทางที่ใช้งานจริง

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

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

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

ตรวจสอบกฎการอนุญาต แล้วจึงตรวจเส้นทางขากลับ

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

เส้นทางขากลับก็สมควรได้รับความสนใจเท่ากัน การเชื่อมต่อ peering ต้องมีเส้นทางใน VPC ของแอปที่ชี้กลับไปยัง CIDR ของไคลเอนต์ กฎของกลุ่มความปลอดภัยที่อนุญาตทราฟฟิกทั้งสองปลาย และ ACL ของเครือข่ายที่ไม่ทิ้งมัน การเข้าถึงได้ทางเดียว ซึ่ง ping ทำงานแต่การจับมือ TCP ไม่ทำงาน มักชี้ไปที่ ACL หรือกลุ่มความปลอดภัย ไม่ใช่ VPN

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

ตรวจสอบด้วยการเชื่อมต่อใหม่ ไม่ใช่คำขอที่โชคดีเพียงครั้งเดียว

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

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