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
Припустимо, маршрутизатор провайдера — 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 лише на цьому інтерфейсі. Сервер, що відповідає на висхідному каналі, конкурує з маршрутизатором провайдера і роздає адреси вашого сегмента решті дому. Прив'яжіть його до інтерфейсу LAN, обмежте оголошеним діапазоном і тримайте власну адресу Pi поза пулом.
Пересилання, трансляція і правило закриття при збої
Чотири речі часто описують як одну, і це не так. Увімкнення пересилання (net.ipv4.ip_forward=1) лише каже ядру, що воно може переміщати пакети між інтерфейсами; саме по собі воно нічого не дозволяє і не гарантує жодного шляху. Вибір виходу — рішення маршрутизації. Дозвіл пакета — рішення політики в ланцюжку forward. Перезапис його джерела — рішення postrouting. Зборка, що робить лише перше, дає Pi, який радо пересилає клієнтський трафік назовні висхідним каналом.
Обмежте дозвіл тими джерелами, які ви мали на увазі, і тим інтерфейсом, який трафік має використовувати, і включіть зворотний шлях і власні потрібні призначення Pi. Потім транслюйте на виході тунелю, якщо провайдер не маршрутизує ваш префікс LAN назад до вас. посібник з nftables розглядає пересилання, локальний вивід і трансляцію джерела як окремі операції, і це тут правильна розумова модель.
Звичайна помилка — широке правило masquerade на фізичному інтерфейсі. Тоді трафік досягає інтернету шляхом провайдера, при цьому з боку клієнта він виглядає точно як робочий 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 кожен потребує рішення, а не висновку.