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 знік. Запішыце гэта як правіла reject, а не як здагадку. Уласны шыфраваны транспарт 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 кожны патрабуе рашэння, а не здагадкі.