รักษาหรือทำ SNAT ไอพีของไคลเอนต์ VPN ที่ขอบคลาวด์

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

สามเงื่อนไขเป็นตัวตัดสิน

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

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

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

เส้นทางไม่ใช่สิทธิ์ในการปลอมแหล่งที่มา

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

aws ec2 describe-instances --instance-ids i-0a1b2c3d4e5f60718 \
  --query "Reservations[].Instances[].SourceDestCheck"
aws ec2 modify-instance-attribute --instance-id i-0a1b2c3d4e5f60718 \
  --no-source-dest-check

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

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

การแปลงซื้ออะไรและแลกกับอะไร

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

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -s 172.20.8.0/24 -o ens5 -j SNAT --to-source 10.40.3.10

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

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

รีเลย์เป็นอินเทอร์เฟซอีกแบบ

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

เฮดเดอร์นั้นเชื่อถือได้ก็ต่อเมื่อแบ็กเอนด์ยอมรับจากพร็อกซี่และไม่ยอมรับจากสิ่งอื่นใด ในแง่ของ nginx นั่นหมายถึงการระบุพีร์ที่เชื่อถือได้อย่างชัดเจนแทนการเชื่อทุกสิ่งที่เข้ามา

set_real_ip_from 10.40.3.10;
real_ip_header X-Forwarded-For;
real_ip_recursive on;

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

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

เขียนลงไปว่าแต่ละขอบเขตเห็นอะไร

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

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