VM ของ GCP ที่มีหลาย NIC: ทำไมการตอบกลับจึงออกทางอินเทอร์เฟซผิด

การเชื่อมต่ออินเทอร์เฟซที่สองเข้ากับ VM ของ Compute Engine ทำให้มีจุดเชื่อมต่อเครือข่ายเพิ่มอีกหนึ่งจุด ไม่ใช่เส้นทางกลับแบบสมมาตร เกสต์ยังคงเลือกอินเทอร์เฟซและที่อยู่ต้นทางจากเส้นทางและกฎของตนเอง จากนั้น Google Cloud จะใช้การกำหนดเส้นทาง VPC และนโยบายไฟร์วอลล์รอบอินเทอร์เฟซที่แพ็กเก็ตออกไป เมื่อการตัดสินใจสองอย่างนี้ไม่ตรงกัน คำขอจะมาถึง NIC ตัวหนึ่งและการตอบกลับจะออกอีกตัวหนึ่ง และสาขาจะเห็นบทสนทนาที่เปิดครึ่งเดียว

ไล่เส้นทางในห้าขั้นตอน แล้วความไม่ตรงกันจะปรากฏก่อนที่คุณจะเขียนกฎนโยบาย

ขั้นตอนที่ 1: จับคู่ NIC ของคลาวด์กับอุปกรณ์ของเกสต์

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

บันทึกที่อยู่ ชื่ออุปกรณ์ และ VPC ที่แต่ละรายการสังกัด แผนที่สามคอลัมน์นั้นคือข้อมูลเข้าของทุกขั้นตอนถัดไป

ขั้นตอนที่ 2: ตั้งชื่อการตัดสินใจด้านเส้นทางสองอย่าง

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

เส้นทางที่มองเห็นได้ใน VPC ที่หันไปทาง VPN ไม่กลายเป็นเส้นทางของเกสต์ที่เลือก NIC ตัวนั้น เส้นทางของคลาวด์อธิบายว่าเครือข่ายส่งมอบอะไรได้ ขณะที่เส้นทางของเกสต์ตัดสินว่าแพ็กเก็ตทำอะไร

ขั้นตอนที่ 3: เลือกนโยบายเส้นทางกลับ

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

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

ขั้นตอนที่ 4: ตรวจสอบตัวกรองของเกสต์เอง

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

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

ขั้นตอนที่ 5: ทดสอบหนึ่งโฟลว์ต่อเส้นทาง

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

แยกการทดสอบสองรายการไว้ในบันทึกของคุณ เพราะใช้เส้นทางต่างกันและกฎไฟร์วอลล์ต่างกัน

สิ่งที่ NIC ตัวที่สองไม่ได้ให้คุณ

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

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