Raspberry Pi-дегі VPN шлюзі: бір желілік карта немесе бөлек клиенттік порт
Pi-дің бір порты таңдалған клиенттерге қызмет ете алады, немесе екінші порт құрылғыларды ішке қамай алады. Схеманы оқшаулау, қайтарым саясаты және DNS кімге тиесілі екеніне қарай таңдаңыз.
Сізде бір Pi, бір жұмыс істейтін шығыс VPN профилі және сол арқылы интернетке шығуы тиіс екі құрылғы бар. Бүкіл құрылысты шешетін сұрақ — қай нұсқаулықты ұстану емес, қанша оқшаулау керек екені. Бір порт Pi-ге сол құрылғылардың қасында маршрутизатордың LAN-ында тұруға және қосымша шлюз ретінде әрекет етуге мүмкіндік береді; екінші порт оларды Pi жалғыз шығу жолы болатын сегментке орналастыруға мүмкіндік береді. Осы таңдаудан кейінгі барлық нәрсе — DHCP, firewall ауқымы, 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-ге мекенжайын орнатылған желілік менеджер арқылы беріңіз, құрылғы үшін онымен таласатын ескі интерфейс файлы рецептісімен емес. Содан кейін клиенттерді баптаңыз: бір құрылғыда статикалық шлюз немесе 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 сияқты көрінеді. Бұл ештеңені дәлелдемейді. Түрлендіруді жарияланған шығысқа байланыстырып ұстаңыз және ережелеріңізді хост қолданып жүрген firewall-да ұстаңыз, ортақ 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 — әрқайсысы шешімді қажет етеді, болжамды емес.