Unha NIC ou dúas? Como decidir a disposición de interfaces dun servidor VPN

Un só adaptador físico abonda para moitos servidores VPN, e tampouco é un deseño universal. A conexión cifrada chega a ese adaptador, o proceso VPN descífraa e o tráfico interior sae por unha interface virtual antes de chegar a un servizo local ou a unha LAN encamiñada. Que isto funcione depende de tres condicións: onde está o destino, se a LAN ten un camiño de volta ao conxunto de clientes e se unha ligazón física compartida lle dá o illamento que afirma. Responda esas tres e o número de adaptadores vén despois.

As tres condicións que o deciden

A primeira condición é o destino. Un servizo no propio host VPN só se alcanza pola interface do túnel, mentres que un host na LAN require reenvío e un camiño de volta. A segunda condición é ese camiño de volta, porque o dispositivo da LAN ten que saber como chegar ao conxunto de clientes, sexa por unha ruta ou por tradución no servidor.

A terceira condición é a separación. Un adaptador significa que cada paquete, cifrado ou non, comparte unha ligazón e normalmente unha cadea de políticas, así que unha afirmación de illamento que depende de hardware separado non a satisfai unha soa interface. Iso é un feito sobre o camiño, non sobre como está configurado o sistema operativo. Aínda pode filtrar o tráfico do túnel, pero non pode afirmar unha fronteira que non ten.

Ningunha das tres trata do número de portos do chasis. Tratan do encamiñamento, da propiedade dos enderezos e de canto depende o deseño da separación física.

Dous adaptadores seguen sendo unha opción lexítima cando zonas físicas, ligazóns ascendentes separadas, rendemento ou un camiño de recuperación fóra de banda o xustifican. Son requisitos concretos, e paga a pena dicilos antes de que alguén encargue hardware.

Cando o servizo se executa no host VPN

O caso máis simple non necesita ningún reenvío. O daemon recibe os paquetes do cliente na interface do túnel e entrégaos a un socket local, e a resposta volve pola mesma interface. O enderezo do conxunto de clientes é un enderezo local real desde o punto de vista do host.

Dúas cousas teñen que estar ben de todos os xeitos: o servizo debe escoitar nun enderezo que o túnel poida alcanzar, e a devasa do host debe aceptar o tráfico que chega á interface do túnel. Ambas son visibles nos comandos de abaixo.

ss -lntup | grep -E "5432|8080"
ip -brief addr show
ip route get 10.8.0.6 from 10.8.0.1

Ligar un servizo só ao enderezo público, ou filtrar a interface do túnel por erro, produce unha conexión que chega ao host e despois morre. Iso parece unha falla de VPN e normalmente é unha decisión de socket ou de devasa.

Cando o destino está na LAN

Aquí é onde un deseño dun só adaptador gaña a súa fama de delicado. O servidor ten que reenviar os paquetes do cliente cara á LAN, e o dispositivo da LAN ten que enviar as respostas de volta ao conxunto de clientes. Ou leva ese conxunto como unha ruta na LAN, ou traduce o enderezo de orixe no servidor para que as respostas volvan ao propio servidor.

Ambas as respostas son lexítimas e fallan de forma distinta. Unha ruta de volta mantén o enderezo orixinal do cliente visible para o destino, o que é bo para os rexistros e malo para regras de devasa que supoñen enderezos de LAN. A tradución mantén a LAN simple e agocha a identidade do cliente ao destino.

sysctl net.ipv4.ip_forward
nft list ruleset | grep -A4 'chain forward'
ip route show table main | grep 10.8.0

Un camiño asimétrico é o síntoma clásico: chega a petición do cliente, a resposta sae por outro encamiñador e a conexión caduca sen ningún erro en ningún dos dous extremos. Capture nos dous lados antes de concluír nada sobre o túnel.

Por que un alias non crea unha segunda zona

Engadir un segundo enderezo ao mesmo adaptador, ou crear unha interface ficticia para imitar un segundo porto, cambia moi pouco. Os paquetes seguen saíndo pola mesma ligazón física, o mesmo porto do conmutador e normalmente a mesma cadea de devasa, así que non existe unha fronteira nova entre eles. É comodidade de configuración, non segmentación. Tratalo como unha fronteira de zona é como unha afirmación de illamento sobrevive só no papel.

Unha zona separada necesita unha separación real no camiño, e ese é o requisito que satisfai un segundo adaptador. Se unha regra depende de que o tráfico orientado a VPN nunca comparta un dominio de difusión co tráfico orientado á LAN, un só cable non pode ofrecer esa propiedade, por moito que se enderece o host.

Onde un produto documenta unha topoloxía multiinterface para un modo concreto, siga a documentación dese produto en lugar de inventar unha solución alternativa. Os provedores tamén cambian as súas topoloxías admitidas entre versións, outra razón para ler a guía actual e non unha captura antiga do asistente.

Comprobe a disposición contra o tráfico que permite

Enumere as clases de tráfico que o servidor debe levar: cliente a host, cliente a LAN, host a LAN e a conexión exterior cifrada. Cada clase ten unha orixe, un destino e unha interface, e a disposición ten que satisfacer as catro á vez. Un deseño que resolve tres delas adoita ser o que xera tíckets.

Despois confirme as interfaces reais e a captura real, non o diagrama do documento de deseño. Os comandos de abaixo imprimen ambas as vistas.

ip -brief addr
ip route
tcpdump -ni any udp port 51820 -c 5
tcpdump -ni tun0 -c 5

Se a captura exterior mostra o tráfico cifrado e a captura interior mostra o tráfico descifrado na interface do túnel mentres o adaptador físico leva ambos, unha soa NIC fai o traballo. Se a captura interior está baleira, o problema está no túnel ou nas regras de reenvío, non no número de adaptadores. Decida a topoloxía a partir desas dúas capturas e da táboa de encamiñamento, e o próximo cambio terá con que medirse.