VPN encamiñada ou ponte: escolla segundo o que o cliente deba acadar

O mesmo día chegan dous tickets: un usuario necesita unha aplicación web interna e un enxeñeiro necesita que un instrumento de banco se comporte como se estivese no mesmo segmento Ethernet. A ambos se lles responde con póñaos na VPN, e aí comeza o problema. Un túnel encamiñado e un túnel ponte estenden relacións distintas, e só unha delas encaixa con cada solicitude. Escoller a topoloxía é unha decisión de acceso, non un axuste de criptografía.

Dúas solicitudes que na ventanilla parecen iguais

O requisito do empregado é un servizo, alcanzable por IP, desde un dispositivo que vostede non controla. O requisito do enxeñeiro é a nivel de enlace: o instrumento espera ver tramas Ethernet e descubrimento por broadcast, e quizais DHCP do segmento no que cre estar.

Son preguntas distintas, e responder ambas cunha ponte amplía o acceso do empregado a toda a LAN da oficina sen motivo.

Escriba o requisito como unha frase antes de escoller: que destinos, que protocolos e que pares deben parecer locais. Se a resposta é un host e un porto, o encamiñamento cóbreo. Se a resposta é unha relación a nivel de trama con dispositivos que só falan broadcast, a ponte pode ser a única opción. Todo o intermedio merece un segmento de proba en lugar da LAN de produción.

Unha ruta é máis estreita que a pertenza á LAN

Un cliente encamiñado obtén un enderezo nunha subrede de túnel e rutas para os prefixos que escolla. Pode acadar o servidor de aplicacións e nada máis, se iso di a política. A pasarela convértese no punto de aplicación, sempre que cada camiño relevante a cruce.

Non confunda unha ruta cun permiso. Dicirlle a un cliente como chegar a unha subrede non lle impide probar outro destino.

Aplique o control de acceso onde realmente poida facer cumprir o fluxo, e manteña os permisos propios da aplicación. Unha regra de reenvío ampla ou unha segunda interface esquecida poden conceder máis do que suxire o diagrama. Lea as regras efectivas, non as previstas. Logo probe un destino que debería fallar, porque unha política que ninguén tentou vulnerar é unha hipótese.

Unha ponte cambia a pregunta de admisión

A ponte combina unha interface física e un dispositivo TAP nun conmutador de software, de xeito que os dispositivos remotos se unen ao mesmo dominio de broadcast. É unha capacidade real e un risco real: o dispositivo remoto xa non é un convidado encamiñado, é un participante.

Decida que dispositivos poden unirse, que tipos de trama deben cruzar e onde se bloquea a interacción non desexada. O enderezo e a autoridade DHCP pasan a formar parte da rede compartida, e dous servidores DHCP nun segmento producen exactamente o desastre que vostede espera.

Para o instrumento, un segmento de proba dedicado adoita encaixar mellor que a LAN da oficina. Manteña o acceso de xestión fóra do experimento e defina como se retira o participante temporal cando remata o traballo.

O filtrado existe en ambas as topoloxías

Unha ponte non é intrínsecamente non filtrable e unha ruta non é intrínsecamente segura. O filtrado de pontes de Linux ten os seus propios ganchos e a súa propia sintaxe de regras, e unha regra escrita para reenvío IP encamiñado non se aplica automaticamente ás tramas de ponte.

Comprobe que admite realmente a plataforma antes de prometer unha fronteira:

bridge link show
nft list ruleset

TUN e TAP describen o tráfico da interface, non o cifrado. Cambiar interfaces non arranxa nada diso: a autenticación de pares, unha chave roubada e unha política criptográfica obsoleta sobreviven todas ao cambio. Ambos os extremos seguen necesitando axustes que coincidan e que aínda se admitan.

Demostre a fronteira con tres intentos

A aceptación son tres observacións, non unha revisión do diagrama. A operación requirida debe funcionar, un destino non relacionado debe fallar e os propios servizos de xestión da pasarela deben quedar fóra de alcance.

Execute o camiño permitido e o denegado desde o mesmo cliente e rexistre ambos:

curl -sS -o /dev/null -w "%{http_code}" http://10.20.0.10/health
ip route get 10.20.0.10
ip route get 10.30.0.5

Para unha ponte, engada as comprobacións a nivel de enlace: se cruza o tráfico de descubrimento permitido, se o enderezo vén da autoridade prevista e se o participante temporal desapareceu tras retiralo. Cando o IP encamiñado simple xa satisface o requisito, unirse ao segmento Ethernet da oficina necesita unha xustificación aparte, e debe escribirse antes do cambio.