Gateway VPN pe Raspberry Pi: o singură placă de rețea sau un port de client dedicat

Aveți un Pi, un profil VPN de ieșire funcțional și două dispozitive care ar trebui să ajungă pe internet prin el. Întrebarea care decide întreaga construcție nu este ce ghid să urmați, ci câtă izolare aveți nevoie. Un singur port lasă Pi-ul să stea lângă acele dispozitive în LAN-ul routerului și să acționeze ca gateway suplimentar; un al doilea port vă permite să le puneți într-un segment în care Pi-ul este singura ieșire. Tot ce urmează după această alegere — DHCP, amploarea firewallului, DNS, cazul căderii — decurge din ea.

Prin ce diferă cu adevărat cele două aranjamente

Ambele construcții rutează. Diferența este cine altcineva stă pe cablu și ce se întâmplă când politica dumneavoastră este greșită.

Izolarea este axa reală. Aranjamentul A este consultativ: un dispozitiv care ignoră gateway-ul primit prin DHCP și alege routerul funcționează în continuare, dar necifrat. Aranjamentul B este impus de topologie, pentru că nu există alt salt următor de ales.

Aranjamentul A: Pi-ul ca gateway suplimentar în LAN-ul existent

Să presupunem că routerul ISP este 192.168.50.1, Pi-ul este 192.168.50.2, iar clienții aleși indică spre Pi. Important este că două fluxuri diferite de pachete împart un singur cablu. Pachetul interior al clientului ajunge la Pi și trebuie să iasă prin tunel; pachetul cifrat propriu al Pi-ului spre partenerul VPN trebuie să iasă prin același cablu spre router. Ele călătoresc în direcții opuse pe aceeași interfață și au nevoie de tratament diferit.

Dați Pi-ului adresa prin managerul de rețea instalat, nu printr-o rețetă veche de fișier de interfață care se ceartă cu el pentru dispozitiv. Apoi configurați clienții: un gateway static pe un dispozitiv, sau o rezervare DHCP care oferă 192.168.50.2 ca router. Nu schimbați întregul interval DHCP al routerului pentru două dispozitive și nu presupuneți că un client respectă opțiunea — verificați.

Slăbiciunea este structurală, nu reparabilă. Orice client din acel segment poate indica 192.168.50.1 și poate ieși necifrat, iar un dispozitiv cu o a doua interfață sau cu radio celular părăsește complet calea dumneavoastră de impunere. Dacă acea propoziție este inacceptabilă pentru dispozitivul respectiv, aveți deja răspunsul: folosiți aranjamentul B.

Aranjamentul B: un port dedicat închide dispozitivele înăuntru

Aici Pi-ul păstrează 192.168.50.2 pe legătura ascendentă cu gateway 192.168.50.1 și ia 10.20.0.1/24 pe o a doua interfață pentru dispozitivele conectate. Pi-ul este acum un router cu două rețele, iar segmentul conectat are exact o ieșire.

Verificați intervalul față de tot restul înainte de a vă angaja: subrețeaua tunelului însuși, alte prefixe între locații și orice este accesibil prin VPN. Un 10.20.0.0/24 care se ciocnește cu un LAN îndepărtat produce acel rezultat pe jumătate funcțional a cărui diagnosticare costă o seară. Dacă al doilea port este un adaptor USB, confirmați că este acceptat și fixați-i numele în managerul de rețea, ca o reordonare după repornire să nu vă mute adresa de LAN.

Rulați ascultătorul DHCP doar pe acea interfață. Un server care răspunde pe legătura ascendentă concurează cu routerul ISP și distribuie adresele segmentului dumneavoastră restului casei. Legați-l de interfața LAN, restricționați-l la intervalul declarat și țineți adresa proprie a Pi-ului în afara grupului.

Redirecționare, traducere și regula de închidere la defecțiune

Patru lucruri sunt adesea descrise ca unul și nu sunt. Activarea redirecționării (net.ipv4.ip_forward=1) spune doar nucleului că poate muta pachete între interfețe; în sine nu permite nimic și nu garantează niciun drum. Alegerea ieșirii este o decizie de rutare. Permiterea pachetului este o decizie de politică în lanțul forward. Rescrierea sursei sale este o decizie de postrouting. O construcție care face doar primul lucru produce un Pi care redirecționează bucuros traficul clienților afară prin legătura ascendentă.

Limitați permisiunea la sursele pe care le-ați avut în vedere și la interfața pe care traficul trebuie să o folosească, și includeți calea de întoarcere și destinațiile de care Pi-ul are nevoie. Apoi traduceți la ieșirea tunelului dacă furnizorul nu vă rutează prefixul LAN înapoi. manualul nftables tratează redirecționarea, ieșirea locală și traducerea sursei ca operațiuni separate, ceea ce este modelul mental corect aici.

Defecțiunea obișnuită este o regulă masquerade largă pe interfața fizică. Atunci traficul ajunge pe internet pe calea ISP, în timp ce, din partea clientului, arată exact ca un VPN funcțional. Asta nu dovedește nimic. Țineți traducerea legată de ieșirea declarată și țineți-vă regulile în firewallul pe care gazda îl folosește deja, în loc să adăugați un set concurent de reguli care golește un lanț postrouting partajat.

Apoi tratați absența tunelului. Un profil de client care instalează o rută implicită largă înseamnă și că, atunci când tunelul cade, ruta implicită obișnuită poate reveni și traficul clienților se întoarce în tăcere pe legătura ascendentă. Acolo unde revenirea la text clar nu este acceptabilă, politica forward trebuie să refuze explicit traficul de la client spre legătura ascendentă, în starea în care ruta VPN a dispărut. Scrieți asta ca regulă de respingere, nu ca presupunere. Transportul cifrat propriu al Pi-ului spre partenerul VPN este un flux local-output separat și trebuie să rămână permis, altfel tunelul nu va putea reveni niciodată.

DNS și IPv6 au nevoie de propriul răspuns

Dacă clienții folosesc Pi-ul ca resolver, ajung la un ascultător local și Pi-ul inițiază o interogare nouă. Acea interogare ascendentă urmează ruta proprie a Pi-ului, nu regula forward pe care ați scris-o pentru clienți, așa că o cale de client doar prin tunel plus un resolver care iese direct este o scurgere fără niciun mesaj de eroare. Decideți deliberat: un resolver accesat prin tunel sau unul local pe care îl acceptați ca direct, și potriviți politica de ieșire proprie a Pi-ului cu acea decizie.

IPv6 este din nou un caz separat. O regulă forward pentru IPv4 nu restricționează nimic în privința IPv6, iar anunțurile de router pe legătura ascendentă pot da Pi-ului, și prin el segmentului conectat, o a doua rută implicită care ocolește politica dumneavoastră. Fie dați IPv6 propria cale protejată după același principiu, fie restricționați-l explicit pe segmentul clienților și spuneți-o.

Testați granița înainte de a avea încredere în ea

Acceptați proiectul doar după patru verificări separate, pentru că testul unic tentant — deschiderea unui browser pe un client — trece în mai multe stări stricate.

Confirmați că un client real ajunge pe internet prin tunel, apoi confirmați că același client nu poate ajunge pe internet cu tunelul căzut. Confirmați că rezolvarea DNS funcționează și că interogarea iese unde intenționați. Confirmați că transportul propriu al Pi-ului încă funcționează după o repornire a tunelului și că recuperarea nu cere repornirea mașinii. În final, verificați un dispozitiv pe care nu l-ați ales: în aranjamentul A ar trebui să funcționeze normal în continuare, iar în aranjamentul B nu ar trebui să existe deloc în acel segment.

• Două porturi și o regulă de respingere dau impunere; un port și o opțiune DHCP dau sfat.
• Traducerea pe interfața greșită pare un succes și nu este.
• Traficul propriu al Pi-ului, DNS și IPv6 au fiecare nevoie de o decizie, nu de o deducție.