Raspberry Pi дээрх VPN гарц: нэг сүлжээний карт эсвэл тусдаа клиентийн порт
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 схем: одоогийн LAN дээрх нэмэлт гарц болох Pi
ISP-ийн чиглүүлэгч 192.168.50.1, Pi нь 192.168.50.2, сонгосон клиентүүд Pi рүү зааж байна гэж үзье. Чухал нь хоёр өөр пакетын урсгал нэг кабелийг хуваалцдаг. Клиентийн дотоод пакет Pi-д хүрч, туннелээр гадагш гарах ёстой; Pi-ийн өөрийн шифрлэгдсэн пакет VPN түнш рүү мөн кабелиар чиглүүлэгч рүү гарах ёстой. Тэд нэг интерфэйсээр эсрэг чиглэлд явж, өөр хандлага шаарддаг.
Pi-д хаягаа суулгасан сүлжээний менежерээр өг, төхөөрөмжийн төлөө түүнтэй тэмцдэг хуучин интерфэйс файлын жороор биш. Дараа нь клиентүүдийг тохируул: нэг төхөөрөмж дээр статик гарц, эсвэл 192.168.50.2-ыг чиглүүлэгч болгон өгдөг DHCP нөөц. Хоёр төхөөрөмжийн төлөө чиглүүлэгчийн бүх DHCP хүрээг бүү өөрчил, клиент энэ сонголтыг хүндэтгэдэг гэж бүү бод — шалга.
Сул тал нь бүтцийн шинжтэй, засах боломжгүй. Тэр сегментийн аль ч клиент 192.168.50.1 рүү зааж ил тод гарч болно, хоёр дахь интерфэйс эсвэл үүрэн радио бүхий төхөөрөмж таны хэрэгжүүлэх замаас бүрэн гарна. Хэрэв тэр өгүүлбэр тухайн төхөөрөмжид хүлээн зөвшөөрөхгүй бол хариулт тань аль хэдийн байна: B схемийг ашигла.
B схем: тусдаа порт төхөөрөмжүүдийг дотроо хаадаг
Энд Pi дээд холбоос дээр 192.168.50.1 гарцтайгаар 192.168.50.2-ыг хадгалж, холбогдсон төхөөрөмжүүдэд зориулж хоёр дахь интерфэйс дээр 10.20.0.1/24-ийг авна. Одоо Pi хоёр сүлжээтэй чиглүүлэгч, холбогдсон сегмент яг нэг гарцтай.
Амлалт өгөхөөс өмнө хүрээг бусад бүх зүйлтэй тулгаж шалга: туннелийн өөрийн дэд сүлжээ, бусад сайт хоорондын угтвар, VPN-ээр хүрэх бүх зүйл. Алслагдсан LAN-тай мөргөлддөг 10.20.0.0/24 нь оношлоход бүтэн орой шаардагддаг хагас ажилладаг үр дүнг өгдөг. Хоёр дахь порт 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 шинэ асуулга эхлүүлнэ. Тэр дээд асуулга нь клиентүүдэд зориулж бичсэн forward дүрмийг биш, Pi-ийн өөрийн маршрутыг дагадаг, тиймээс зөвхөн туннелээр явдаг клиентийн зам дээр шууд гардаг шийдэгчийг нэмэх нь ямар ч алдааны мэдэгдэлгүй алдагдал юм. Зориуд шийд: туннелээр хүрэх шийдэгч үү, эсвэл шууд гэж хүлээн зөвшөөрсөн локал шийдэгч үү, Pi-ийн өөрийн гаралтын бодлогыг тэр шийдвэртэй нийцүүл.
IPv6 дахин тусдаа тохиолдол. IPv4-д зориулсан forward дүрэм IPv6-ийн талаар юу ч хязгаарлахгүй, дээд холбоос дээрх чиглүүлэгчийн зарлалууд Pi-д болон түүгээр дамжуулан холбогдсон сегментэд таны бодлогыг тойрсон хоёр дахь анхдагчыг өгч болно. Нэг бол ижил зарчмаар IPv6-д өөрийн хамгаалагдсан замыг өг, эсвэл клиентийн сегмент дээр тодорхой хязгаарлаж, тэгж хэл.
Итгэхээс өмнө хил хязгаарыг шалга
Загварыг дөрвөн тусдаа шалгалтын дараа л хүлээн зөвшөөр, учир нь уруу татдаг ганц тест — нэг клиент дээр хөтөч нээх — хэд хэдэн эвдэрсэн төлөвт давдаг.
Нэг бодит клиент туннелээр интернетэд хүрч байгааг батал, дараа нь тэр клиент туннел унасан үед интернетэд хүрч чадахгүйг батал. DNS шийдэл ажиллаж, асуулга таны санасан газраас гарч байгааг батал. Туннелийг дахин ачаалсны дараа ч Pi-ийн өөрийн тээвэр ажиллаж, сэргээхэд машиныг дахин ачаалах шаардлагагүйг батал. Эцэст нь таны сонгоогүй төхөөрөмжийг шалга: A схемд тэр хэвийн ажилласаар байх ёстой, B схемд тэр сегмент дээр огт байх ёсгүй.
- Хоёр порт, нэг хориглох дүрэм хэрэгжүүлэлт өгдөг; нэг порт, нэг DHCP сонголт зөвлөмж өгдөг.
- Буруу интерфэйс дээрх орчуулга амжилт мэт харагдаж, амжилт биш.
- Pi-ийн өөрийн урсгал, DNS болон IPv6 тус бүр шийдвэр шаардана, таамаг биш.