Gateway ng VPN sa Raspberry Pi: isang network card o hiwalay na port ng kliyente

Mayroon kang isang Pi, isang gumaganang palabas na profile ng VPN, at dalawang device na dapat makarating sa internet sa pamamagitan nito. Ang tanong na nagtatakda ng buong pagtatayo ay hindi kung aling gabay ang susundin, kundi kung gaano karaming paghihiwalay ang kailangan mo. Ang isang port ay nagpapahintulot sa Pi na tumabi sa mga device na iyon sa LAN ng router at kumilos bilang karagdagang gateway; ang ikalawang port ay nagpapahintulot sa iyo na ilagay sila sa segment kung saan ang Pi ang tanging labasan. Lahat ng pagkatapos ng pagpipiliang iyon — DHCP, saklaw ng firewall, DNS, ang kaso ng pagkawala — ay nagmumula roon.

Ano ang tunay na pagkakaiba ng dalawang layout

Parehong nagruruta ang dalawang disenyo. Ang pagkakaiba ay kung sino pa ang nakatayo sa kable at ano ang nangyayari kapag mali ang patakaran mo.

Ang paghihiwalay ang tunay na aksis. Ang layout A ay payo lamang: ang device na binabalewala ang gateway mula sa DHCP at pinipili ang router ay gumagana pa rin, ngunit walang encryption. Ang layout B ay ipinapatupad ng topolohiya, dahil walang ibang susunod na hakbang na mapipili.

Layout A: ang Pi bilang karagdagang gateway sa umiiral na LAN

Ipagpalagay na ang router ng ISP ay 192.168.50.1, ang Pi ay 192.168.50.2, at ang mga piling kliyente ay tumuturo sa Pi. Mahalaga na dalawang magkaibang daloy ng packet ang naghahati sa isang kable. Dumarating sa Pi ang panloob na packet ng kliyente at dapat lumabas sa tunnel; ang sariling naka-encrypt na packet ng Pi patungo sa kapareha ng VPN ay dapat lumabas sa parehong kable patungo sa router. Naglalakbay sila sa magkasalungat na direksyon sa parehong interface at nangangailangan ng magkaibang pagtrato.

Ibigay sa Pi ang address nito sa pamamagitan ng naka-install na tagapamahala ng network, hindi sa lumang resipe ng file ng interface na nakikipag-away dito para sa device. Pagkatapos ay i-set up ang mga kliyente: static na gateway sa isang device, o reserbasyon ng DHCP na nagbibigay ng 192.168.50.2 bilang router. Huwag baguhin ang buong saklaw ng DHCP ng router dahil sa dalawang device, at huwag ipagpalagay na iginagalang ng kliyente ang opsyon — i-verify ito.

Ang kahinaan ay istruktural, hindi naaayos. Anumang kliyente sa segment na iyon ay maaaring tumuro sa 192.168.50.1 at lumabas nang hayagan, at ang device na may ikalawang interface o cellular radio ay tuluyang lumalabas sa iyong landas ng pagpapatupad. Kung hindi katanggap-tanggap ang pangungusap na iyon para sa device na iyon, mayroon ka nang sagot: gamitin ang layout B.

Layout B: kinukulong ng hiwalay na port ang mga device sa loob

Dito pinapanatili ng Pi ang 192.168.50.2 sa uplink kasama ang gateway 192.168.50.1, at kumukuha ng 10.20.0.1/24 sa ikalawang interface para sa mga konektadong device. Ang Pi ay router na may dalawang network, at ang konektadong segment ay may eksaktong isang labasan.

Suriin ang saklaw laban sa lahat ng iba pa bago ka magtali: ang sariling subnet ng tunnel, iba pang prefix sa pagitan ng mga site, at lahat ng maaabot sa pamamagitan ng VPN. Ang 10.20.0.0/24 na bumabangga sa malayong LAN ay nagbibigay ng kalahating-gumaganang resulta na isang gabi ang halaga sa pag-diagnose. Kung ang ikalawang port ay USB adapter, tiyakin na sinusuportahan ito at i-pin ang pangalan nito sa tagapamahala ng network para hindi ilipat ng muling pagkakasunod-sunod pagkatapos ng reboot ang iyong address sa LAN.

Patakbuhin ang tagapakinig ng DHCP sa interface na iyon lamang. Ang server na sumasagot sa uplink ay nakikipagkumpitensya sa router ng ISP at namimigay ng mga address ng segment mo sa iba pang bahagi ng bahay. Ikabit ito sa interface ng LAN, limitahan ito sa idineklarang saklaw, at ilayo ang sariling address ng Pi mula sa pool.

Pagpapasa, pagsasalin at ang tuntunin ng pagsasara sa pagkabigo

Apat na bagay ang madalas ilarawan bilang isa at hindi ito isa. Ang pag-on ng pagpapasa (net.ipv4.ip_forward=1) ay nagsasabi lamang sa kernel na maaari nitong ilipat ang mga packet sa pagitan ng mga interface; wala itong pinapayagan sa sarili nito at walang ginagarantiyahang landas. Ang pagpili ng labasan ay desisyon sa routing. Ang pagpayag sa packet ay desisyon sa patakaran sa forward chain. Ang muling pagsulat ng pinagmulan nito ay desisyon sa postrouting. Ang pagtatayo na ginagawa lamang ang una ay nagbubunga ng Pi na masayang nagpapasa ng trapik ng kliyente palabas sa uplink.

Limitahan ang pahintulot sa mga pinagmulang nilayon mo at sa interface na dapat gamitin ng trapik, at isama ang daan pabalik at ang mga patutunguhang kailangan ng Pi. Pagkatapos ay isalin sa labasan ng tunnel kung hindi ibinalik ng provider ang prefix ng iyong LAN sa iyo. manwal ng nftables tinatrato ang pagpapasa, lokal na output at pagsasalin ng pinagmulan bilang magkahiwalay na operasyon, at iyon ang tamang modelo ng pag-iisip dito.

Ang karaniwang pagkabigo ay malawak na tuntunin ng masquerade sa pisikal na interface. Pagkatapos ay nararating ng trapik ang internet sa daan ng ISP habang, mula sa panig ng kliyente, mukhang eksaktong gumaganang VPN. Walang pinapatunayan iyon. Panatilihing nakatali ang pagsasalin sa idineklarang labasan, at itago ang iyong mga tuntunin sa firewall na ginagamit na ng host, sa halip na magdagdag ng konkurenteng set ng tuntunin na nagpapalabas ng nilalamang postrouting chain.

Pagkatapos ay harapin ang kawalan ng tunnel. Ang profile ng kliyente na nag-iinstall ng malawak na default route ay nangangahulugan din na kapag bumagsak ang tunnel, maaaring bumalik ang ordinaryong default at tahimik na bumabalik ang trapik ng kliyente sa uplink. Kung saan hindi katanggap-tanggap ang pagbabalik sa hayag na teksto, doon ang patakaran ng forward ay dapat tahasang tanggihan ang trapik mula sa kliyente patungo sa uplink, sa kalagayang wala na ang ruta ng VPN. Isulat iyon bilang tuntunin ng pagtanggi, hindi bilang palagay. Ang sariling naka-encrypt na transportasyon ng Pi patungo sa kapareha ng VPN ay hiwalay na daloy ng local-output at dapat manatiling pinapayagan, kung hindi ay hindi na makakabalik ang tunnel.

Ang DNS at IPv6 ay may kani-kanilang sagot

Kung ginagamit ng mga kliyente ang Pi bilang resolver, nararating nila ang lokal na tagapakinig at nagsisimula ang Pi ng bagong query. Ang query na iyon pataas ay sumusunod sa sariling ruta ng Pi, hindi sa tuntunin ng forward na isinulat mo para sa mga kliyente, kaya ang landas ng kliyente na dumaan lamang sa tunnel kasama ang resolver na direktang lumalabas ay pagtagas na walang anumang mensahe ng error. Magpasya nang sinasadya: resolver na naaabot sa pamamagitan ng tunnel, o lokal na tinatanggap mo bilang direkta, at itugma ang sariling patakaran ng output ng Pi sa desisyong iyon.

Ang IPv6 ay hiwalay na kaso muli. Ang tuntunin ng forward para sa IPv4 ay walang nililimitahan tungkol sa IPv6, at ang mga anunsyo ng router sa uplink ay maaaring magbigay sa Pi, at sa pamamagitan nito sa konektadong segment, ng ikalawang default na lumalabag sa iyong patakaran. O bigyan ang IPv6 ng sariling protektadong landas sa parehong prinsipyo, o limitahan ito nang tahasan sa segment ng kliyente at sabihin iyon.

Subukin ang hangganan bago mo ito pagkatiwalaan

Tanggapin ang disenyo pagkatapos lamang ng apat na magkahiwalay na pagsusuri, dahil ang nakakaakit na iisang pagsubok — magbukas ng browser sa isang kliyente — ay pumapasa sa ilang sirang kalagayan.

Tiyakin na ang isang tunay na kliyente ay nakakarating sa internet sa pamamagitan ng tunnel, pagkatapos ay tiyakin na ang parehong kliyente ay hindi makakarating sa internet kapag nakababa ang tunnel. Tiyakin na gumagana ang resolusyon ng DNS at lumalabas ang query kung saan mo ito nilayon. Tiyakin na gumagana pa rin ang transportasyon ng Pi pagkatapos ng restart ng tunnel, at hindi kailangan ng reboot ng makina ang pagbangon. Sa huli, suriin ang isang device na hindi mo pinili: sa layout A dapat itong magpatuloy nang normal, at sa layout B dapat wala talaga ito sa segment na iyon.

• Dalawang port at tuntunin ng pagtanggi ang nagbibigay ng pagpapatupad; isang port at opsyon ng DHCP ang nagbibigay ng payo.
• Ang pagsasalin sa maling interface ay mukhang tagumpay at hindi.
• Ang sariling trapik ng Pi, DNS at IPv6 ay bawat isa ay nangangailangan ng desisyon, hindi haka-haka.