VPN เกตเวย์บน Raspberry Pi: การ์ดเครือข่ายใบเดียวหรือพอร์ตไคลเอนต์แยก
พอร์ตเดียวของ Pi ให้บริการไคลเอนต์ที่เลือกได้ หรือพอร์ตที่สองจะกักอุปกรณ์ไว้ภายในก็ได้ เลือกแบบตามการกักกัน นโยบายสำรอง และใครเป็นเจ้าของ DNS
คุณมี Pi หนึ่งเครื่อง โปรไฟล์ VPN ขาออกที่ใช้งานได้หนึ่งโปรไฟล์ และอุปกรณ์สองเครื่องที่ควรออกอินเทอร์เน็ตผ่านมัน คำถามที่กำหนดการสร้างทั้งหมดไม่ใช่ว่าจะทำตามคู่มือเล่มไหน แต่เป็นว่าคุณต้องการการกักกันมากแค่ไหน พอร์ตเดียวทำให้ Pi วางอยู่ข้างอุปกรณ์เหล่านั้นบน LAN ของเราเตอร์และทำหน้าที่เป็นเกตเวย์เพิ่มเติม พอร์ตที่สองทำให้คุณวางมันไว้ในเซกเมนต์ที่ Pi เป็นทางออกเดียว ทุกอย่างหลังจากตัวเลือกนั้น — DHCP ขอบเขตไฟร์วอลล์ DNS กรณีที่หลุด — ล้วนต่อจากมัน
สองแบบต่างกันจริง ๆ ตรงไหน
ทั้งสองแบบกำหนดเส้นทาง ความต่างคือใครอื่นยืนอยู่บนสายและเกิดอะไรขึ้นเมื่อนโยบายของคุณผิด
| Layout A: Pi on the ISP LAN | Layout B: dedicated client port | |
|---|---|---|
| Cabling | One Ethernet port, existing switch port | Two interfaces: uplink plus a separate LAN port |
| Can a client bypass the Pi? | Yes, by using the ISP router as its gateway | No, unless the device has another radio or link |
| Who hands out addresses | The ISP router, with a per-client setting or a DHCP option | The Pi, on its own LAN interface only |
| Blast radius of a mistake | Any LAN host, if a rule is too broad | The attached segment |
| Good fit for | One laptop, a console, a temporary test client | Appliances, always-on boxes, untrusted devices |
แกนจริงคือการกักกัน แบบ A เป็นเพียงคำแนะนำ อุปกรณ์ที่เพิกเฉยต่อเกตเวย์ที่ DHCP ให้มาแล้วเลือกเราเตอร์ก็ยังทำงานได้ แต่ไม่มีการเข้ารหัส แบบ B ถูกบังคับด้วยโครงสร้าง เพราะไม่มีฮ็อปถัดไปอื่นให้เลือก
แบบ A: Pi เป็นเกตเวย์เพิ่มเติมบน LAN เดิม
สมมติว่าเราเตอร์ ISP คือ 192.168.50.1 Pi คือ 192.168.50.2 และไคลเอนต์ที่เลือกชี้มาที่ Pi สิ่งสำคัญคือสองกระแสแพ็กเก็ตที่ต่างกันใช้สายเดียวร่วมกัน แพ็กเก็ตภายในของไคลเอนต์มาถึง Pi และต้องออกผ่านอุโมงค์ แพ็กเก็ตที่เข้ารหัสของ Pi เองไปยังคู่ VPN ต้องออกผ่านสายเดียวกันไปยังเราเตอร์ ทั้งสองเดินทางสวนทางกันบนอินเทอร์เฟซเดียวกันและต้องการการจัดการต่างกัน
ให้ที่อยู่กับ Pi ผ่านตัวจัดการเครือข่ายที่ติดตั้งไว้ ไม่ใช่ผ่านสูตรไฟล์อินเทอร์เฟซเก่าที่แย่งอุปกรณ์กับมัน จากนั้นตั้งค่าไคลเอนต์: เกตเวย์แบบคงที่บนอุปกรณ์หนึ่ง หรือการจอง DHCP ที่แจก 192.168.50.2 เป็นเราเตอร์ อย่าเปลี่ยนขอบเขต DHCP ทั้งหมดของเราเตอร์เพราะอุปกรณ์สองเครื่อง และอย่าสันนิษฐานว่าไคลเอนต์เคารพตัวเลือกนั้น — ตรวจสอบ
จุดอ่อนเป็นเชิงโครงสร้าง ไม่ใช่สิ่งที่แก้ได้ ไคลเอนต์ใดก็ได้ในเซกเมนต์นั้นชี้ไปที่ 192.168.50.1 แล้วออกไปแบบข้อความธรรมดา และอุปกรณ์ที่มีอินเทอร์เฟซที่สองหรือวิทยุเซลลูลาร์ก็ออกจากเส้นทางการบังคับของคุณไปเลย หากประโยคนั้นยอมรับไม่ได้สำหรับอุปกรณ์นั้น คุณมีคำตอบอยู่แล้ว: ใช้แบบ B
แบบ B: พอร์ตเฉพาะกักอุปกรณ์ไว้ภายใน
ที่นี่ Pi รักษา 192.168.50.2 บนลิงก์ต้นทางด้วยเกตเวย์ 192.168.50.1 และรับ 10.20.0.1/24 บนอินเทอร์เฟซที่สองสำหรับอุปกรณ์ที่เชื่อมต่อ ตอนนี้ Pi เป็นเราเตอร์ที่มีสองเครือข่าย และเซกเมนต์ที่เชื่อมต่อมีทางออกเดียวเท่านั้น
ตรวจสอบช่วงกับทุกอย่างอื่นก่อนผูกมัด: ซับเน็ตของอุโมงค์เอง คำนำหน้าข้ามไซต์อื่น และทุกสิ่งที่เข้าถึงได้ผ่าน VPN 10.20.0.0/24 ที่ชนกับ LAN ระยะไกลให้ผลลัพธ์แบบครึ่ง ๆ กลาง ๆ ที่ต้องใช้เวลาวินิจฉัยทั้งคืน หากพอร์ตที่สองเป็นอะแดปเตอร์ USB ให้ยืนยันว่ารองรับและปักชื่อไว้ในตัวจัดการเครือข่าย เพื่อการจัดลำดับใหม่หลังรีบูตจะไม่ย้ายที่อยู่ LAN ของคุณ
รันตัวฟัง DHCP บนอินเทอร์เฟซนั้นเท่านั้น เซิร์ฟเวอร์ที่ตอบบนลิงก์ต้นทางจะแข่งขันกับเราเตอร์ ISP และแจกที่อยู่ของเซกเมนต์คุณให้ส่วนที่เหลือของบ้าน ผูกกับอินเทอร์เฟซ LAN จำกัดให้อยู่ในช่วงที่ประกาศ และเก็บที่อยู่ของ Pi เองไว้นอกพูล
การส่งต่อ การแปล และกฎการปิดเมื่อล้มเหลว
สี่สิ่งมักถูกอธิบายเป็นสิ่งเดียวและไม่ใช่ การเปิดการส่งต่อ (net.ipv4.ip_forward=1) บอกเคอร์เนลเพียงว่าย้ายแพ็กเก็ตระหว่างอินเทอร์เฟซได้ ตัวมันเองไม่อนุญาตอะไรและไม่รับประกันเส้นทางใด การเลือกทางออกเป็นการตัดสินใจเรื่องเส้นทาง การอนุญาตแพ็กเก็ตเป็นการตัดสินใจเชิงนโยบายในเชน forward การเขียนที่มาใหม่เป็นการตัดสินใจ postrouting การสร้างที่ทำเพียงอย่างแรกจะได้ Pi ที่ส่งต่อทราฟฟิกไคลเอนต์ออกไปทางลิงก์ต้นทางอย่างมีความสุข
จำกัดการอนุญาตให้เฉพาะแหล่งที่คุณตั้งใจและอินเทอร์เฟซที่ทราฟฟิกควรใช้ และรวมเส้นทางกลับและปลายทางที่ Pi ต้องการ จากนั้นแปลที่ทางออกของอุโมงค์หากผู้ให้บริการไม่กำหนดเส้นทางคำนำหน้า LAN ของคุณกลับมาหาคุณ คู่มือ nftables มองการส่งต่อ เอาต์พุตภายใน และการแปลที่มาเป็นปฏิบัติการแยกกัน ซึ่งเป็นแบบคิดที่ถูกต้องในที่นี้
ความล้มเหลวทั่วไปคือกฎ masquerade แบบกว้างบนอินเทอร์เฟซกายภาพ แล้วทราฟฟิกก็ไปถึงอินเทอร์เน็ตทางเส้นทาง ISP ขณะที่ฝั่งไคลเอนต์ดูเหมือน VPN ที่ทำงานได้พอดี นั่นไม่ได้พิสูจน์อะไรเลย ให้การแปลผูกกับทางออกที่ประกาศไว้ และเก็บกฎไว้ในไฟร์วอลล์ที่โฮสต์ใช้อยู่แล้ว แทนที่จะเพิ่มชุดกฎคู่แข่งที่ล้างเชน postrouting ที่ใช้ร่วมกัน
จากนั้นจัดการกับการไม่มีอุโมงค์ โปรไฟล์ไคลเอนต์ที่ติดตั้งเส้นทางเริ่มต้นแบบกว้างยังหมายความว่าเมื่ออุโมงค์ล่ม เส้นทางเริ่มต้นปกติอาจกลับมาและทราฟฟิกไคลเอนต์ก็กลับไปทางลิงก์ต้นทางอย่างเงียบ ๆ ในกรณีที่ การถอยกลับไปเป็นข้อความธรรมดาไม่เป็นที่ยอมรับ นโยบาย forward ต้องปฏิเสธทราฟฟิกจากไคลเอนต์ไปยังลิงก์ต้นทางอย่างชัดเจน ในสถานะที่เส้นทาง VPN หายไป เขียนสิ่งนั้นเป็นกฎปฏิเสธ ไม่ใช่ข้อสันนิษฐาน การขนส่งที่เข้ารหัสของ Pi เองไปยังคู่ VPN เป็นกระแส local-output แยกและต้องยังคงได้รับอนุญาต ไม่อย่างนั้นอุโมงค์จะไม่มีวันกลับมา
DNS และ IPv6 ต้องการคำตอบของตัวเอง
ถ้าไคลเอนต์ใช้ Pi เป็นตัวแปลงชื่อ พวกมันจะไปถึงตัวฟังภายในและ Pi เริ่มคำถามใหม่ คำถามต้นทางนั้นเดินตามเส้นทางของ Pi เอง ไม่ใช่กฎ forward ที่คุณเขียนให้ไคลเอนต์ ดังนั้นเส้นทางไคลเอนต์ที่ผ่านอุโมงค์เท่านั้นบวกตัวแปลงชื่อที่ออกไปตรง ๆ จึงเป็นการรั่วโดยไม่มีข้อความแสดงข้อผิดพลาดใด ๆ ตัดสินใจอย่างตั้งใจ: ตัวแปลงชื่อที่เข้าถึงผ่านอุโมงค์ หรือตัวแปลงชื่อภายในที่คุณยอมรับว่าเป็นทางตรง แล้วทำให้นโยบายเอาต์พุตของ Pi เองตรงกับการตัดสินใจนั้น
IPv6 เป็นอีกกรณีหนึ่ง กฎ forward สำหรับ IPv4 ไม่จำกัดอะไรเกี่ยวกับ IPv6 และการประกาศของเราเตอร์บนลิงก์ต้นทางอาจให้เส้นทางเริ่มต้นที่สองแก่ Pi และผ่านมันไปยังเซกเมนต์ที่เชื่อมต่อ ซึ่งเลี่ยงนโยบายของคุณ ไม่ว่าจะให้ IPv6 มีเส้นทางป้องกันของตัวเองตามหลักเดียวกัน หรือจำกัดมันอย่างชัดเจนบนเซกเมนต์ไคลเอนต์แล้วบอกเช่นนั้น
ทดสอบขอบก่อนจะเชื่อถือ
ยอมรับการออกแบบหลังการตรวจสอบแยกกันสี่ครั้งเท่านั้น เพราะการทดสอบเดี่ยวที่ล่อใจ — เปิดเบราว์เซอร์บนไคลเอนต์หนึ่งเครื่อง — ผ่านได้ในหลายสถานะที่พัง
ยืนยันว่าไคลเอนต์จริงหนึ่งเครื่องเข้าถึงอินเทอร์เน็ตผ่านอุโมงค์ แล้วยืนยันว่าไคลเอนต์เดียวกันเข้าถึงอินเทอร์เน็ตไม่ได้เมื่ออุโมงค์ลง ยืนยันว่าการแปลง DNS ทำงานและคำถามออกไปในที่ที่คุณตั้งใจ ยืนยันว่าการขนส่งของ Pi เองยังทำงานหลังรีสตาร์ตอุโมงค์ และการกู้คืนไม่ต้องรีบูตเครื่อง สุดท้ายตรวจอุปกรณ์ที่คุณไม่ได้เลือก: ในแบบ A มันควรทำงานตามปกติต่อไป และในแบบ B มันไม่ควรมีอยู่บนเซกเมนต์นั้นเลย
- สองพอร์ตกับกฎปฏิเสธให้การบังคับ ส่วนพอร์ตเดียวกับตัวเลือก DHCP ให้คำแนะนำ
- การแปลบนอินเทอร์เฟซผิดดูเหมือนความสำเร็จและไม่ใช่
- ทราฟฟิกของ Pi เอง DNS และ IPv6 แต่ละอย่างต้องการการตัดสินใจ ไม่ใช่การอนุมาน