AWS Client VPN แบบแยกอุโมงค์: ควรเผยแพร่เส้นทางใด

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

ธงแยกอุโมงค์ไม่ใช่รายการปลายทาง

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

อ่านตารางเส้นทางของปลายทางและเส้นทางที่ติดตั้งในไคลเอนต์ไปพร้อมกัน ป้ายกำกับบอกเจตนา เส้นทางบอกว่าเกิดอะไรขึ้น

การตัดสินใจข้อแรก: ทราฟฟิกอินเทอร์เน็ตทั่วไปควรอยู่ในเครื่องหรือไม่

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

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

การตัดสินใจข้อสอง: คำนำหน้าส่วนตัวใด และได้รับอนุญาตจากใคร

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

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

เมื่อปลายทางต้องเข้าถึงได้ด้วยชื่อ ให้สังเกตว่าคำถามถัดไปคือการแก้ชื่อ ไม่ใช่เส้นทาง

การตัดสินใจข้อสาม: ตัวแก้ไขชื่อใดตามอุโมงค์

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

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

เปลี่ยนชุดเส้นทาง แล้วตรวจสอบทั้งสองโลก

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

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

เขียนรายการเส้นทางลงในรันบุ๊กข้างเหตุผล เพื่อให้คนถัดไปแยกการยกเว้นโดยเจตนาออกจากการหลงลืม