VPN แบบเราเตอร์หรือแบบบริดจ์: เลือกตามสิ่งที่ไคลเอนต์ต้องเข้าถึง

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

สองคำขอที่ดูเหมือนกันที่เคาน์เตอร์ตั๋ว

ความต้องการของพนักงานคือบริการที่เข้าถึงได้ผ่าน IP จากอุปกรณ์ที่คุณไม่ได้ควบคุม ความต้องการของวิศวกรอยู่ที่ระดับลิงก์: เครื่องมือคาดว่าจะเห็นเฟรม Ethernet และการค้นหาด้วยการออกอากาศ และอาจรวมถึง DHCP จากเซกเมนต์ที่มันคิดว่าตัวเองอยู่

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

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

เส้นทางแคบกว่าการเป็นสมาชิก LAN

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

อย่าสับสนระหว่างเส้นทางกับสิทธิ์ การบอกไคลเอนต์ว่าจะไปถึงซับเน็ตได้อย่างไรไม่ได้หยุดมันจากการลองปลายทางอื่น

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

บริดจ์เปลี่ยนคำถามเรื่องการรับเข้า

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

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

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

การกรองมีอยู่ในทั้งสองโทโพโลยี

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

ตรวจสอบว่าแพลตฟอร์มรองรับอะไรจริงก่อนสัญญาเรื่องขอบเขต:

bridge link show
nft list ruleset

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

พิสูจน์ขอบเขตด้วยสามความพยายาม

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

รันเส้นทางที่อนุญาตและที่ถูกปฏิเสธจากไคลเอนต์เดียวกัน และบันทึกทั้งสอง:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

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