NIC หนึ่งตัวหรือสองตัว? การตัดสินใจเลือกโครงสร้างอินเทอร์เฟซของเซิร์ฟเวอร์ VPN

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

สามเงื่อนไขที่กำหนด

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

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

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

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

เมื่อบริการทำงานบนโฮสต์ VPN

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

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

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

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

เมื่อจุดหมายอยู่ใน LAN

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

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

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

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

ทำไม alias จึงไม่สร้างโซนที่สอง

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

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

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

ตรวจสอบโครงสร้างเทียบกับทราฟฟิกที่คุณอนุญาต

ระบุชั้นของทราฟฟิกที่เซิร์ฟเวอร์ต้องรับ ได้แก่ ไคลเอนต์ไปยังโฮสต์ ไคลเอนต์ไปยัง LAN โฮสต์ไปยัง LAN และการเชื่อมต่อภายนอกที่เข้ารหัส แต่ละชั้นมีต้นทาง จุดหมาย และอินเทอร์เฟซ และโครงสร้างต้องตอบสนองทั้งสี่พร้อมกัน การออกแบบที่จัดการสามอย่างมักเป็นตัวที่สร้างตั๋วสนับสนุน

จากนั้นยืนยันอินเทอร์เฟซจริงและการเก็บแพ็กเก็ตจริง ไม่ใช่แผนภาพในเอกสารออกแบบ คำสั่งด้านล่างแสดงทั้งสองมุมมอง

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

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