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 ар бири чечимди талап кылат, божомолду эмес.