VPN шлюз на Raspberry Pi: един мрежов порт или отделен клиентски порт
Един порт на Raspberry Pi може да обслужва избрани клиенти, или втори порт може да огради устройствата. Изберете схема по изолация, политика при отказ и по това кой притежава DNS.
Имате едно Raspberry Pi, един работещ изходящ VPN профил и две устройства, които трябва да достигат интернет през него. Въпросът, който решава цялата постройка, не е кое ръководство да следвате, а колко изолация ви е нужна. Един порт позволява на Raspberry Pi да стои до тези устройства в LAN на рутера и да действа като допълнителен шлюз; втори порт ви позволява да ги поставите в сегмент, където Raspberry 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: Raspberry Pi като допълнителен шлюз в съществуващата LAN
Да приемем, че ISP рутерът е 192.168.50.1, Raspberry Pi е 192.168.50.2, а избраните клиенти сочат към Raspberry Pi. Важното е, че два различни потока от пакети споделят един кабел. Вътрешният пакет на клиента пристига в Raspberry Pi и трябва да излезе през тунела; собственият шифрован пакет на Raspberry Pi към VPN партньора трябва да излезе през същия кабел към рутера. Те пътуват в противоположни посоки по един и същ интерфейс и се нуждаят от различно третиране.
Дайте адреса на Raspberry Pi през инсталирания мрежов мениджър, а не през стара рецепта с файл за интерфейса, която се бори с него за устройството. След това настройте клиентите: статичен шлюз на едно устройство или DHCP резервация, която подава 192.168.50.2 като рутер. Не променяйте целия DHCP обхват на рутера заради две устройства и не предполагайте, че клиентът зачита опцията — проверете го.
Слабостта е структурна, а не поправима. Всеки клиент в този сегмент може да сочи към 192.168.50.1 и да излезе без шифроване, а устройство с втори интерфейс или клетъчно радио напуска пътя ви на принуда напълно. Ако това изречение е неприемливо за въпросното устройство, вече имате отговора: използвайте схема B.
Схема B: отделен порт огражда устройствата
Тук Raspberry Pi запазва 192.168.50.2 на връзката нагоре с шлюз 192.168.50.1 и взема 10.20.0.1/24 на втори интерфейс за прикачените устройства. Сега Raspberry Pi е рутер с две мрежи, а прикаченият сегмент има точно един изход.
Проверете диапазона срещу всичко останало, преди да се ангажирате: собствената подмрежа на тунела, други префикси между сайтове и всичко достъпно през VPN. 10.20.0.0/24, която се сблъсква с отдалечена LAN, дава онзи полуработещ резултат, чиято диагностика отнема цяла вечер. Ако вторият порт е USB адаптер, потвърдете, че се поддържа, и закрепете името му в мрежовия мениджър, така че пренареждане след рестарт да не премести LAN адреса ви.
Пуснете DHCP слушателя само на този интерфейс. Сървър, който отговаря на връзката нагоре, се състезава с ISP рутера и раздава адресите на вашия сегмент на останалата част от дома. Вържете го към LAN интерфейса, ограничете го до обявения диапазон и дръжте собствения адрес на Raspberry Pi извън пула.
Препращане, транслация и правилото за затваряне при отказ
Четири неща често се описват като едно и не са. Включването на препращането (net.ipv4.ip_forward=1) само казва на ядрото, че може да мести пакети между интерфейси; то само по себе си не разрешава нищо и не гарантира никакъв път. Изборът на изхода е решение за маршрутизация. Разрешаването на пакета е решение за политика във веригата forward. Пренаписването на източника му е решение за postrouting. Постройка, която прави само първото, дава Raspberry Pi, който охотно препраща клиентски трафик навън през връзката нагоре.
Ограничете разрешението до източниците, които имате предвид, и до интерфейса, който трафикът трябва да използва, и включете обратния път и собствените нужни дестинации на Raspberry Pi. След това транслейте на изхода на тунела, ако доставчикът не маршрутизира вашия LAN префикс обратно към вас. ръководството на nftables третира препращането, локалния изход и транслацията на източника като отделни операции, което е правилният мисловен модел тук.
Честата повреда е широко правило masquerade на физическия интерфейс. Тогава трафикът достига интернет по ISP пътя, докато от страна на клиента изглежда точно като работещ VPN. Това не доказва нищо. Дръжте транслацията вързана към обявения изход и дръжте правилата си в защитната стена, която хостът вече използва, вместо да добавяте конкурентен набор правила, който изчиства споделена postrouting верига.
След това се заемете с отсъствието на тунела. Клиентски профил, който инсталира широк маршрут по подразбиране, означава също, че когато тунелът падне, обичайният маршрут по подразбиране може да се върне и клиентският трафик тихо се връща към връзката нагоре. Там, където връщането към открит текст е неприемливо, политиката forward трябва изрично да отказва трафик от клиент към връзката нагоре, в състоянието, в което VPN маршрутът е изчезнал. Напишете го като правило за отказ, не като предположение. Собственият шифрован транспорт на Raspberry Pi до VPN партньора е отделен поток local-output и трябва да остане разрешен, иначе тунелът никога не може да се върне.
DNS и IPv6 се нуждаят от собствен отговор
Ако клиентите използват Raspberry Pi като резолвер, те попадат на локален слушател и Raspberry Pi създава нова заявка. Тази заявка нагоре следва собствения маршрут на Raspberry Pi, а не правилото forward, което сте написали за клиентите, така че клиентски път само през тунела плюс резолвер, който излиза директно, е изтичане без никакво съобщение за грешка. Решете съзнателно: резолвер, достъпен през тунела, или локален, който приемате като директен, и накарайте собствената изходна политика на Raspberry Pi да съответства на това решение.
IPv6 отново е отделно. Правило forward за IPv4 не ограничава нищо относно IPv6, а обявите на рутера по връзката нагоре могат да дадат на Raspberry Pi, а чрез него и на прикачения сегмент, втори маршрут по подразбиране, който заобикаля политиката ви. Или дайте на IPv6 собствен защитен път на същия принцип, или го ограничете изрично в клиентския сегмент и го кажете.
Тествайте границата, преди да ѝ вярвате
Приемете проекта само след четири отделни проверки, защото изкушаващият единичен тест — отваряне на браузър на един клиент — минава в няколко счупени състояния.
Потвърдете, че един реален клиент достига интернет през тунела, после потвърдете, че същият клиент не може да достигне интернет при паднал тунел. Потвърдете, че DNS резолюцията работи и че заявката излиза там, където сте искали. Потвърдете, че собственият транспорт на Raspberry Pi още работи след рестарт на тунела и че възстановяването не изисква рестарт на машината. Накрая проверете устройство, което не сте избрали: при схема A то трябва да продължи да работи нормално, а при схема B не трябва изобщо да съществува в този сегмент.
- Два порта и правило за отказ дават принуда; един порт и DHCP опция дават съвет.
- Транслация на грешния интерфейс изглежда като успех и не е.
- Собственият трафик на Raspberry Pi, DNS и IPv6 всяко се нуждае от решение, не от извод.