VPN-pordego sur Raspberry Pi: unu retkarto aŭ aparta klienta pordo
Unu pordo de la Pi povas servi elektitajn klientojn, aŭ dua pordo povas fermi la aparatojn ene. Elektu la aranĝon laŭ izolado, rezerva politiko kaj tio, kiu posedas DNS.
Vi havas unu Pi, unu funkciantan elirantan VPN-profilo, kaj du aparatoj, kiuj devus atingi la interreton tra ĝi. La demando, kiu decidas la tutan konstruaĵon, ne estas kiun gvidilon sekvi, sed kiom da izolado vi bezonas. Unu pordo lasas la Pi stari apud tiuj aparatoj en la LAN de la enkursigilo kaj agi kiel plia pordego; dua pordo lasas vin meti ilin en segmenton, kie la Pi estas la sola eliro. Ĉio post tiu elekto — DHCP, amplekso de la fajroŝirmilo, DNS, la kazo de paneo — sekvas el ĝi.
En kio la du aranĝoj vere diferencas
Ambaŭ dezajnoj enkursigas. La diferenco estas, kiu alia staras sur la kablo kaj kio okazas, kiam via politiko estas malĝusta.
| 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 |
Izolado estas la vera akso. Aranĝo A estas konsila: aparato, kiu ignoras la pordegon donitan de DHCP kaj elektas la enkursigilon, ankoraŭ funkcias, sed neĉifrite. Aranĝo B estas devigata de la topologio, ĉar ne ekzistas alia sekva salto por elekti.
Aranĝo A: la Pi kiel plia pordego en la ekzistanta LAN
Supozu, ke la enkursigilo de la ISP estas 192.168.50.1, la Pi estas 192.168.50.2, kaj la elektitaj klientoj montras al la Pi. Gravas, ke du malsamaj pakaĵfluoj dividas unu kablon. La interna pakaĵo de la kliento alvenas al la Pi kaj devas eliri tra la tunelo; la propra ĉifrita pakaĵo de la Pi al la VPN-partnero devas eliri tra la sama kablo al la enkursigilo. Ili vojaĝas en kontraŭaj direktoj sur la sama interfaco kaj bezonas malsaman traktadon.
Donu al la Pi sian adreson per la instalita retadministrilo, ne per malnova recepto de interfaca dosiero, kiu batalas kun ĝi pri la aparato. Poste agordu la klientojn: statika pordego sur unu aparato, aŭ DHCP-rezervo, kiu donas 192.168.50.2 kiel enkursigilon. Ne ŝanĝu la tutan DHCP-amplekson de la enkursigilo pro du aparatoj, kaj ne supozu, ke kliento respektas la opcion — kontrolu ĝin.
La malforto estas struktura, ne riparigebla. Ĉiu kliento en tiu segmento povas montri al 192.168.50.1 kaj eliri malkaŝe, kaj aparato kun dua interfaco aŭ poŝtelefona radio tute forlasas vian devigan vojon. Se tiu frazo estas neakceptebla por la koncerna aparato, vi jam havas la respondon: uzu aranĝon B.
Aranĝo B: aparta pordo baras la aparatojn ene
Ĉi tie la Pi tenas 192.168.50.2 sur la suprenligo kun pordego 192.168.50.1, kaj prenas 10.20.0.1/24 sur dua interfaco por la alkroĉitaj aparatoj. Nun la Pi estas enkursigilo kun du retoj, kaj la alkroĉita segmento havas precize unu eliron.
Kontrolu la gamon kontraŭ ĉio alia antaŭ ol sindevontigi: la propra subreto de la tunelo, aliaj prefiksoj inter ejoj, kaj ĉio atingebla tra la VPN. 10.20.0.0/24, kiu kolizias kun fora LAN, produktas tiun duonfunkcian rezulton, kies diagnozo kostas vesperon. Se la dua pordo estas USB-adaptilo, konfirmu, ke ĝi estas subtenata, kaj fiksu ĝian nomon en la retadministrilo, por ke reordigo post restartiĝo ne movu vian LAN-adreson.
Funkciigu la DHCP-aŭskultanton nur sur tiu interfaco. Servilo, kiu respondas sur la suprenligo, konkuradas kun la enkursigilo de la ISP kaj disdonas la adresojn de via segmento al la resto de la domo. Ligu ĝin al la LAN-interfaco, limigu ĝin al la deklarita gamo, kaj tenu la propran adreson de la Pi ekster la baseno.
Plusendado, tradukado kaj la regulo de fermo ĉe paneo
Kvar aferoj ofte estas priskribataj kiel unu kaj ne estas. Ŝalti plusendadon (net.ipv4.ip_forward=1) nur diras al la kerno, ke ĝi rajtas movi pakaĵojn inter interfacoj; ĝi mem permesas nenion kaj garantias neniun vojon. Elekti la eliron estas enkursiga decido. Permesi la pakaĵon estas politika decido en la forward-ĉeno. Reskribi ĝian fonton estas postrouting-decido. Konstruaĵo, kiu faras nur la unuan, rezultigas Pi, kiu ĝoje plusendas klientan trafikon eksteren tra la suprenligo.
Limigu la permeson al la fontoj, kiujn vi celis, kaj al la interfaco, kiun la trafiko uzu, kaj inkluzivu la revenan vojon kaj la proprajn necesajn celojn de la Pi. Poste traduku sur la tunela eliro, se la provizanto ne enkursigas vian LAN-prefikson reen al vi. manlibro de nftables traktas plusendadon, lokan eligon kaj fontan tradukadon kiel apartajn operaciojn, kio estas la ĝusta pensmodelo ĉi tie.
La ordinara paneo estas larĝa masquerade-regulo sur la fizika interfaco. Tiam la trafiko atingas la interreton tra la ISP-vojo, dum ĝi de la klienta flanko aspektas precize kiel funkcianta VPN. Tio pruvas nenion. Tenu la tradukadon ligita al la deklarita eliro, kaj tenu viajn regulojn en la fajroŝirmilo, kiun la gastiganto jam uzas, anstataŭ aldoni konkurencan regulkolekton, kiu malplenigas komunan postrouting-ĉenon.
Poste traktu la foreston de la tunelo. Klienta profilo, kiu instalas larĝan defaŭltan vojon, ankaŭ signifas, ke kiam la tunelo falas, la ordinara defaŭlto povas reveni kaj la klienta trafiko silente revenas al la suprenligo. Kie reveno al klara teksto ne estas akceptebla, la forward-politiko devas eksplicite malpermesi trafikon de kliento al la suprenligo, en la stato, en kiu la VPN-vojo mankas. Skribu tion kiel malpermesan regulon, ne kiel supozon. La propra ĉifrita transporto de la Pi al la VPN-partnero estas aparta local-output-fluo kaj devas resti permesata, alie la tunelo neniam povas reveni.
DNS kaj IPv6 bezonas sian propran respondon
Se klientoj uzas la Pi kiel solvilon, ili trafas lokan aŭskultanton kaj la Pi lanĉas novan demandon. Tiu suprena demando sekvas la propran vojon de la Pi, ne la forward-regulon, kiun vi skribis por klientoj, do klienta vojo nur tra la tunelo plus solvilo, kiu eliras rekte, estas liko sen ia ajn erarmesaĝo. Decidu konscie: solvilo atingata tra la tunelo, aŭ loka, kiun vi akceptas kiel rektan, kaj adaptu la propran eligpolitikon de la Pi al tiu decido.
IPv6 denove estas aparta afero. Forward-regulo por IPv4 limigas nenion rilate al IPv6, kaj enkursigilaj anoncoj sur la suprenligo povas doni al la Pi, kaj tra ĝi al la alkroĉita segmento, duan defaŭlton, kiu preteriras vian politikon. Aŭ donu al IPv6 sian propran protektitan vojon laŭ la sama principo, aŭ limigu ĝin eksplicite en la klienta segmento kaj diru tion.
Testu la limon antaŭ ol fidi ĝin
Akceptu la dezajnon nur post kvar apartaj kontroloj, ĉar la tentiga ununura test — malfermi retumilon sur unu kliento — sukcesas en pluraj rompitaj statoj.
Konfirmu, ke unu reala kliento atingas la interreton tra la tunelo, poste konfirmu, ke la sama kliento ne povas atingi la interreton kun la tunelo malsupre. Konfirmu, ke DNS-solvado funkcias kaj ke la demando eliras tien, kien vi intencis. Konfirmu, ke la propra transporto de la Pi ankoraŭ funkcias post restartiĝo de la tunelo, kaj ke la restaŭro ne postulas restartiĝon de la maŝino. Fine, kontrolu aparaton, kiun vi ne elektis: sub aranĝo A ĝi devus daŭre funkcii normale, kaj sub aranĝo B ĝi tute ne devus ekzisti en tiu segmento.
- Du pordoj kaj malpermesa regulo donas devigon; unu pordo kaj DHCP-opcio donas konsilon.
- Tradukado sur la malĝusta interfaco aspektas kiel sukceso kaj ne estas.
- La propra trafiko de la Pi, DNS kaj IPv6 ĉiu bezonas decidon, ne konkludon.