IP ของไคลเอนต์ VPN ใน Kubernetes: เก็บไว้หรือทำ SNAT?
เลือกว่าจะเก็บที่อยู่จริงของไคลเอนต์ VPN หรือใช้ NAT ต้นทางใน Kubernetes โดยอิงสามเงื่อนไข แล้วตรวจสอบเส้นทางขากลับและการหมุนเวียนของ pod
ที่ใดที่หนึ่งระหว่างอุโมงค์กับ backend ที่อยู่ของไคลเอนต์จะอยู่รอดหรือถูกแทนที่ และผลลัพธ์ทั้งสองแบบก็ป้องกันได้ การเลือกเป็นของเจ้าของบริการที่รับ ไม่ใช่ของคนที่ติดตั้ง CNI เมื่อการอนุญาตรายไคลเอนต์ โควตา หรือบันทึกการตรวจสอบมีความสำคัญ ที่อยู่ต้องอยู่รอดทุกฮอป เมื่อการระบุที่มาร่วมกันเป็นที่ยอมรับ NAT ต้นทางจะกำจัดปัญหาเส้นทางที่คุณจะต้องดูแลตลอดไป
ที่อยู่ของไคลเอนต์หายไปจริงที่ไหน
แพ็กเก็ตของไคลเอนต์ระยะไกลมาถึง pod ของ VPN ด้วยต้นทางภายในช่วงอุโมงค์ สมมติว่า 10.90.0.42 เมื่อ pod ส่งต่อแพ็กเก็ตนั้นไปยัง ClusterIP หรือ IP ของ pod กลไกที่แตกต่างกันสามอย่างสามารถเขียนต้นทางใหม่ได้ กฎ masquerade ของ CNI บนโหนดครอบคลุมทราฟฟิกที่ pod ส่งออกนอก CIDR ของคลัสเตอร์ ส่วนรายการ conntrack ของ kube-proxy บนโหนดปลายทางครอบคลุมฮอปไปยัง Service เอง พร็อกซีที่ปิดการเชื่อมต่อจะไม่ส่งต่อแพ็กเก็ตเลย ดังนั้นต้นทางที่คุณเห็นในที่สุดจึงเป็นของพร็อกซี
แต่ละอย่างอยู่ในเลเยอร์ที่ต่างกัน จึงแทบไม่มีฟิลด์ Service ใดซ่อมเส้นทางทั้งหมดได้
externalTrafficPolicy บน Service สาธารณะของ VPN ตัดสินใจเพียงว่าเกิดอะไรกับการเชื่อมต่อภายนอก: Local เก็บที่อยู่ระยะไกลไว้บนโหนดที่รับไว้ ขณะที่ Cluster ให้ kube-proxy ส่งแพ็กเก็ตให้โหนดอื่นและทำ masquerade ที่นั่น การตั้งค่านั้นควบคุม listener ที่ไคลเอนต์ของคุณเชื่อมต่อด้วย มันไม่ได้บอกอะไรเกี่ยวกับแพ็กเก็ตที่ถอดรหัสแล้วซึ่งกระบวนการ VPN ของคุณส่งเข้าคลัสเตอร์ในภายหลัง
สามเงื่อนไขที่ตัดสินข้อโต้แย้ง
ฉันถามคำถามสามข้อเดิมในลำดับเดิมทุกครั้งที่เรื่องนี้เกิดขึ้น เพราะข้อแรกมักจบการถกเถียง ตอบคำถามเหล่านั้นสำหรับภาระงานนั้น ๆ ไม่ใช่ทั้งคลัสเตอร์ สองคลัสเตอร์ในบริษัทเดียวอาจได้คำตอบต่างกันและทั้งคู่ถูกต้อง
| Question | Preserve | SNAT |
|---|---|---|
| Does the backend enforce policy per client? | Yes, the address is the identity | Only if a trusted proxy supplies identity |
| Can the cluster route 10.90.0.0/24 back to a stable gateway? | Required | Not needed |
| Is the workload a forwarder or a proxy? | Forwarder | Proxy is fine |
ถ้า backend ตอบว่าใช่ในคำถามแรกและไม่ใช่ในข้อที่สอง คุณมีงานเครือข่ายต้องทำ ไม่ใช่งานแก้ manifest ถ้าแถวที่สามบอกว่าพร็อกซี ที่อยู่นั้นไม่มีทางอยู่รอดตั้งแต่แรก และการอ้างตรงข้ามต้องแลกด้วยการดักแพ็กเก็ตหนึ่งสัปดาห์
โหมด preserve ต้องการอะไรจากเครือข่าย
การเก็บต้นทางหมายความว่าโหนดปลายทางต้องส่งทราฟฟิกกลับไปยัง 10.90.0.42 ผ่านเกตเวย์ VPN ที่ทำงานอยู่ พูลของ VPN ไม่ใช่ CIDR ของคลัสเตอร์ จึงไม่มี CNI ใดกำหนดเส้นทางให้คุณโดยค่าเริ่มต้น คุณเพิ่มเส้นทางเองแล้วตรวจสอบให้แน่ใจว่าปลายทางของเกตเวย์ที่มันชี้ไปนั้นอยู่รอดการจัดตารางใหม่
ip route add 10.90.0.0/24 via 10.244.3.17 dev eth0
sysctl -w net.ipv4.conf.eth0.rp_filter=2ฮอปถัดไปคือที่อยู่ของ pod และที่อยู่ของ pod เคลื่อนที่ กำหนดเส้นทางไปยัง VIP ของ Service หรือที่อยู่โหนดที่อยู่กับที่ หรือยอมรับว่าคุณจะไล่ตามเกตเวย์หลังการขับออกทุกครั้ง การกรองเส้นทางย้อนกลับเป็นกับดักอีกอย่าง: โหมดเข้มงวดจะทิ้งแพ็กเก็ตที่เส้นทางขากลับไม่ตรงกับอินเทอร์เฟซที่มันเข้ามา ซึ่งเป็นรูปร่างของโฟลว์ VPN ที่เก็บไว้พอดี
การตรวจสอบแบบหลวมมักเป็นความแตกต่างระหว่างเส้นทางขากลับที่ใช้งานได้กับ คำตอบที่หายไปหลังจากออกจาก backend กฎ masquerade บนโหนด VPN ก็ต้องยกเว้นช่วงอุโมงค์ด้วย ไม่เช่นนั้นแพ็กเก็ตที่ส่งต่อจะออกไปพร้อมที่อยู่ของ pod ไม่ว่าคุณจะสร้างเส้นทางแบบใด ควรแสดงข้อยกเว้นนั้นในการกำหนดค่าของ CNI เองแทนการแก้ iptables ด้วยมือ เพราะเอเจนต์เขียนเชนใหม่เมื่อเริ่มทำงาน และกฎที่คุณเขียนด้วยมือจะอยู่รอดจนถึงการอัปเกรดครั้งถัดไปพอดี
NetworkPolicy เป็นการควบคุมการเข้าถึง ไม่ใช่การกำหนดเส้นทาง การเข้มงวดนโยบายจะไม่คืนที่อยู่ที่ masquerade แทนที่ไปแล้ว
SNAT มีต้นทุนอะไร และจะบันทึกไว้อย่างไร
NAT ต้นทางเข้าสู่คลัสเตอร์เป็นการออกแบบที่ถูกกว่า และไม่ใช่ความผิดพลาด backend เห็นที่อยู่ของ pod หรือโหนด VPN บันทึกต่าง ๆ สอดคล้องกัน และไม่จำเป็นต้องมีเส้นทางขากลับ สิ่งที่คุณเสียไปคือความสามารถในการแยกไคลเอนต์สองรายในเลเยอร์เครือข่าย ดังนั้นโควตา การแบน และร่องรอยการตรวจสอบต้องมาจากที่อื่น
โดยปกติที่อื่นนั้นคือแอปพลิเคชัน: โทเค็นเซสชัน ส่วนหัวที่ลงนาม หรือบรรทัดโปรโตคอล PROXY ที่เขียนโดยพร็อกซีที่คุณควบคุม สิ่งเหล่านี้ให้ตัวตนแก่ผู้รับที่เชื่อถือได้ก็ต่อเมื่อพร็อกซีอยู่ในเส้นทางและส่วนหัวไม่สามารถตั้งค่าจากฝั่งไคลเอนต์ได้ ระบุให้ชัดใน runbook ว่าอันไหนใช้บังคับ เพราะวิศวกรคนถัดไปจะถือว่าที่อยู่ในบันทึกคือไคลเอนต์ มันไม่ใช่ และเหตุการณ์ครั้งเดียวก็พอจะทำให้สมมติฐานนั้นมีราคาแพง
การแลกเปลี่ยนยังคงซื่อตรงตราบเท่าที่มันถูกเขียนไว้
การตรวจสอบที่แยกเส้นทางที่ใช้งานได้ออกจากเส้นทางที่โชคดี
ทดสอบด้วยการเชื่อมต่อใหม่ ไม่ใช่ที่แคชไว้ และทดสอบทั้งสองทิศทาง ความล้มเหลวหลายอย่างดูเหมือนเป็นครั้งคราวเพียงเพราะโฟลว์ใหม่ใช้เส้นทางที่เขียนใหม่
ดัก tuple ที่สามจุดระหว่างคำขอที่ได้รับอนุญาตหนึ่งครั้ง: ทันทีหลังถอดห่อ ที่อินเทอร์เฟซขาออกของ pod VPN และที่ backend ถ้าต้นทางเปลี่ยนระหว่างการดักครั้งที่สองกับครั้งที่สาม สาเหตุอยู่ต่ำกว่าลงมาจาก pod ถ้าเปลี่ยนก่อนครั้งที่สอง ตัว pod เองกำลังแปล
จากนั้นลบ pod VPN และทำการทดสอบซ้ำขณะที่มันถูกจัดตารางใหม่ เส้นทางที่เก็บไว้ซึ่งแตกเมื่อถูกขับออกยังไม่สมบูรณ์ และกฎ NAT ที่ผูกกับที่อยู่ซึ่งไม่มีอยู่แล้วก็เช่นกัน สุดท้าย ส่งคำขอหนึ่งครั้งจากต้นทางที่คุณคาดว่าจะถูกปฏิเสธ และยืนยันว่าการปฏิเสธมาจากนโยบาย ไม่ใช่จากเส้นทางที่หายไป