EC2 Elastic IP ไม่ใช่ที่อยู่ VPN ส่วนตัวของอินสแตนซ์

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

สองที่อยู่ หนึ่งอินสแตนซ์

อินเทอร์เฟซเครือข่ายของอินสแตนซ์ถือที่อยู่ส่วนตัวภายใน VPC และนั่นคือที่อยู่ที่แขกรู้จัก Elastic IP เชื่อมโยงกับอินเทอร์เฟซเดียวกันแต่อาศัยอยู่ฝั่งสาธารณะของการแมป

ทุกสิ่งที่จะมาถึงอินสแตนซ์ผ่านอินเทอร์เน็ตมาถึงโดยถูกแปลเป็นที่อยู่ส่วนตัว ทุกสิ่งที่อินสแตนซ์ส่งออกอินเทอร์เน็ตออกไปโดยมี Elastic IP เป็นต้นทาง อีกครั้งเพราะการแปลนั้น

ภายในแขกมีที่อยู่เดียว ภายนอกมีสอง ความไม่สมมาตรนี้อธิบายความสับสนส่วนใหญ่ในด้านนี้ แขกไม่สามารถกำหนดค่าสิ่งที่เกตเวย์แปลได้ ทำได้เพียงตอบบนที่อยู่ที่ถืออยู่จริง

เกตเวย์อินเทอร์เน็ตทำอะไรจริง ๆ

เอกสารของ AWS เกี่ยวกับเกตเวย์อินเทอร์เน็ต อธิบายการจัดวาง: อินสแตนซ์รับรู้ที่อยู่ IPv4 ส่วนตัวของตน และเกตเวย์ให้การแปลเป็น IPv4 สาธารณะหรือ Elastic IP ที่สอดคล้องกันสำหรับทราฟฟิกบนเส้นทางอินเทอร์เน็ต

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

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

ทำไมกลลวงอินเทอร์เฟซอุโมงค์จึงล้มเหลว

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

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

ที่อยู่ไม่เคยเป็นปัญหา การเลือกเส้นทางต่างหากที่เป็น

สามเป้าหมาย สามการออกแบบ

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

หากเป้าหมายคือการเข้าถึงแอปพลิเคชันแบบส่วนตัว ปลายทางคือที่อยู่ส่วนตัวหรือชื่อ DNS ส่วนตัวที่แปลงไปยังที่อยู่นั้น และเส้นทาง VPN กลุ่มความปลอดภัย และเส้นทางขากลับต้องสอดคล้องกันทั้งหมด Elastic IP ไม่ปรากฏเลยในการออกแบบนั้น

หากเป้าหมายคืออัตลักษณ์ขาออกสาธารณะที่มั่นคงสำหรับผู้ใช้ VPN นั่นคือการออกแบบ NAT ฝั่งขาออก ไม่ใช่ที่อยู่บนอุโมงค์ของไคลเอนต์ สามเป้าหมายที่ฟังดูคล้ายกันให้แผนภาพที่ต่างกันสามแบบ และมีเพียงแบบเดียวเท่านั้นที่เกี่ยวข้องกับการวาง Elastic IP ไว้ในที่ใหม่

ตรวจสอบเส้นทางที่คุณเลือก

สำหรับการเข้าถึงแบบส่วนตัว ตรวจสอบว่าเส้นทาง VPN ครอบคลุมคำนำหน้าส่วนตัว ตารางเส้นทางของ VPC ส่งทราฟฟิกกลับไปยังอุโมงค์ กลุ่มความปลอดภัยอนุญาตต้นทางของไคลเอนต์ และไฟร์วอลล์ของไคลเอนต์เองอนุญาตการตอบกลับ จากนั้นทดสอบคำขอจริงหนึ่งรายการแทน ping

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

หากชื่อโฮสต์สาธารณะต้องทำงานจากทั้งสองฝั่ง ให้ใช้การออกแบบ DNS ที่ตอบด้วยที่อยู่ส่วนตัวสำหรับไคลเอนต์ VPN และที่อยู่สาธารณะสำหรับคนอื่น ๆ และเก็บใบรับรองให้ใช้ได้กับชื่อไม่ใช่ที่อยู่ ลำดับงาน: ตั้งชื่อเป้าหมาย เลือกที่อยู่ที่เป็นของมัน แล้วตรวจสอบเส้นทาง นโยบาย และคำขอหนึ่งรายการ