ทำไม GRE และ ESP จึงล้มเหลวผ่านเกตเวย์ NAT ของ AWS

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

ชุดกฎไม่ใช่ชุดโปรโตคอล

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

ข้อกำหนด โปรโตคอลของเกตเวย์ NAT ของ AWS ระบุ TCP, UDP และ ICMP สำหรับบริการแบบจัดการ นั่นคือชุดที่รองรับทั้งหมด กฎอนุญาตสำหรับโปรโตคอล IP อื่นไม่สามารถขยายได้ เพราะกฎถูกประเมินนานก่อนที่จะถึงเส้นทางส่งต่อของเกตเวย์

ความแตกต่างนี้สำคัญเพราะความล้มเหลวทั้งสองดูเหมือนกันจากฝั่งไคลเอนต์และมีวิธีแก้ที่ต่างกันโดยสิ้นเชิง

PPTP แสดงให้เห็นว่าทำไมการทดสอบพอร์ตจึงโกหก

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

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

เหตุผลเดียวกันใช้กับโปรโตคอลใดก็ตามที่มีช่องควบคุมเป็น TCP หรือ UDP ขณะที่เส้นทางข้อมูลไม่ใช่

IPsec อยู่รอดได้เพียงในรูป UDP

IPsec เป็นกรณีที่คำตอบมีเงื่อนไขไม่ใช่การปฏิเสธแบบตรง ๆ AWS บันทึก NAT traversal ว่าเป็นรูปแบบที่รองรับสำหรับ IPsec ผ่านเกตเวย์ NAT เมื่อเจรจา NAT-T แล้ว ESP จะถูกห่อหุ้มภายใน UDP และเกตเวย์เห็น UDP ธรรมดาแทนโปรโตคอล 50

การอนุญาต UDP 4500 ไม่ได้ทำให้ปลายทางใช้ NAT traversal มันอนุญาตแพ็กเก็ตเฉพาะเมื่อมีรูปแบบนั้นอยู่แล้ว ยืนยันจากเอาต์พุตการเจรจาของไคลเอนต์เองว่าเลือกการห่อหุ้มแบบใด และยืนยันฝั่งรับว่าคู่ตรงข้ามยอมรับ ปลายทางสองจุดที่กำหนดค่าสำหรับ ESP แบบดั้งเดิมจะยังคงส่ง ESP แบบดั้งเดิมไม่ว่าชุดกฎจะกล่าวอย่างไร

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

ตรวจสอบเส้นทางก่อนขยายนโยบาย

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

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

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

เมื่อการขนส่งไม่พอดี

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

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

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