Pasarela VPN en Raspberry Pi: unha NIC ou un porto de cliente dedicado

Ten unha Pi, un perfil VPN de saída que funciona e dous dispositivos que deberían chegar a internet a través dela. A pregunta que decide toda a construción non é que guía seguir, senón canta contención necesita. Un só porto permite que a Pi se sitúe xunto a eses dispositivos na LAN do router e actúe como pasarela adicional; un segundo porto permítelle poñelos nun segmento onde a Pi é a única saída. Todo o que vén despois desa elección — DHCP, alcance da devasa, DNS, o caso de caída — derívase dela.

En que se diferencian realmente os dous deseños

Ambos os deseños encamiñan. A diferenza é quen máis está no cable e que pasa cando a súa política é incorrecta.

A contención é o eixe real. O deseño A é orientativo: un dispositivo que ignora a pasarela entregada por DHCP e escolle o router segue funcionando, sen cifrar. O deseño B imponse por topoloxía, porque non hai outro salto seguinte que escoller.

Deseño A: a Pi como pasarela adicional na LAN existente

Supoña que o router do ISP é 192.168.50.1, a Pi é 192.168.50.2 e os clientes elixidos apuntan á Pi. O importante é que dous fluxos de paquetes distintos comparten un só cable. O paquete interno do cliente chega á Pi e debe saír polo túnel; o paquete cifrado propio da Pi cara ao par VPN debe saír polo mesmo cable cara ao router. Viaxan en direccións opostas pola mesma interface e necesitan un tratamento distinto.

Dea á Pi o seu enderezo mediante o xestor de rede instalado, non cunha receita antiga de ficheiro de interface que compite con el polo dispositivo. Logo configure os clientes: unha pasarela estática nun dispositivo, ou unha reserva DHCP que entrega 192.168.50.2 como router. Non cambie todo o ámbito DHCP do router por dous dispositivos, e non dea por feito que un cliente respecta a opción — verifíqueo.

A debilidade é estrutural, non reparábel. Calquera cliente dese segmento pode apuntar a 192.168.50.1 e saír en claro, e un dispositivo cunha segunda interface ou unha radio celular abandona por completo a súa ruta de aplicación. Se esa frase é inaceptable para o dispositivo en cuestión, xa ten a resposta: use o deseño B.

Deseño B: un porto dedicado pecha os dispositivos dentro

Aquí a Pi conserva 192.168.50.2 na ligazón ascendente con pasarela 192.168.50.1, e toma 10.20.0.1/24 nunha segunda interface para os dispositivos conectados. Agora a Pi é un router con dúas redes, e o segmento conectado ten exactamente unha saída.

Comprobe o rango contra todo o demais antes de comprometerse: a subrede propia do túnel, outros prefixos entre sedes e calquera cousa alcanzable a través da VPN. Un 10.20.0.0/24 que choca cunha LAN remota produce ese resultado a medio funcionar que custa unha tarde de diagnóstico. Se o segundo porto é un adaptador USB, confirme que é compatible e fixe o seu nome no xestor de rede para que unha reordenación tras o reinicio non mova o seu enderezo de LAN.

Execute o oínte DHCP só nesa interface. Un servidor que responde na ligazón ascendente compite co router do ISP e entrega os enderezos do seu segmento ao resto da casa. Áteo á interface LAN, restrínxao ao rango declarado e manteña o enderezo propio da Pi fóra do conxunto.

Reenvío, tradución e a regra de peche ante fallo

Catro cousas descríbense a miúdo como unha e non o son. Habilitar o reenvío (net.ipv4.ip_forward=1) só lle di ao núcleo que pode mover paquetes entre interfaces; non permite nada por si mesmo nin garante ningún camiño. Escoller a saída é unha decisión de encamiñamento. Permitir o paquete é unha decisión de política na cadea forward. Reescribir a súa orixe é unha decisión de postrouting. Unha construción que só fai o primeiro produce unha Pi que reenvía alegremente o tráfico dos clientes cara á ligazón ascendente.

Limite o permiso ás fontes que pretendía e á interface que o tráfico debe usar, e inclúa o camiño de volta e os destinos que a Pi necesita. Logo traduza na saída do túnel se o provedor non lle encamiña de volta o prefixo da súa LAN. manual de nftables trata o reenvío, a saída local e a tradución de orixe como operacións separadas, que é o modelo mental correcto aquí.

O fallo habitual é unha regra masquerade ampla na interface física. Entón o tráfico chega a internet pola ruta do ISP mentres, desde o lado do cliente, parece exactamente unha VPN que funciona. Non demostra nada. Manteña a tradución ligada á saída declarada e manteña as súas regras na devasa que o host xa usa, en lugar de engadir un conxunto de regras competidor que baleira unha cadea postrouting compartida.

Despois aborde a ausencia do túnel. Un perfil de cliente que instala unha ruta por defecto ampla tamén significa que, cando o túnel cae, a ruta por defecto ordinaria pode volver e o tráfico do cliente regresa en silencio á ligazón ascendente. Onde a volta a texto claro non é aceptable, a política forward debe denegar explicitamente o tráfico de cliente á ligazón ascendente, no estado en que a ruta VPN desapareceu. Escríbao como unha regra de rexeitamento, non como unha suposición. O transporte cifrado propio da Pi cara ao par VPN é un fluxo local-output aparte e debe seguir permitido, ou o túnel nunca poderá volver.

DNS e IPv6 necesitan a súa propia resposta

Se os clientes usan a Pi como resolutor, chegan a un oínte local e a Pi orixina unha consulta nova. Esa consulta ascendente segue a ruta propia da Pi, non a regra forward que escribiu para os clientes, así que unha ruta de cliente só polo túnel máis un resolutor que sae directamente é unha fuga sen ningunha mensaxe de erro. Decídao a propósito: un resolutor alcanzado polo túnel, ou un local que acepte como directo, e faga que a política de saída propia da Pi coincida con esa decisión.

IPv6 é de novo un caso aparte. Unha regra forward de IPv4 non restrinxe nada sobre IPv6, e os anuncios de router na ligazón ascendente poden dar á Pi, e a través dela ao segmento conectado, unha segunda ruta por defecto que esquiva a súa política. Ou ben dea a IPv6 o seu propio camiño protexido co mesmo principio, ou ben restrínxao explicitamente no segmento de clientes e dígao.

Probe a fronteira antes de confiar nela

Acepte o deseño só tras catro comprobacións separadas, porque a tentadora proba única — abrir un navegador nun cliente — pasa en varios estados rotos.

Confirme que un cliente real chega a internet polo túnel, e logo confirme que ese mesmo cliente non pode chegar a internet co túnel caído. Confirme que a resolución DNS funciona e que a consulta sae onde vostede quería. Confirme que o transporte propio da Pi segue funcionando tras un reinicio do túnel, e que a recuperación non esixe reiniciar a máquina. Por último, comprobe un dispositivo que non escolleu: co deseño A debería seguir funcionando con normalidade, e co deseño B non debería existir en absoluto nese segmento.

• Dous portos e unha regra de denegación dan aplicación; un porto e unha opción DHCP dan consello.
• A tradución na interface equivocada parece un éxito e non o é.
• O tráfico propio da Pi, o DNS e IPv6 necesitan cada un unha decisión, non unha inferencia.