Enviar todo a un só host ou reescribir tamén o porto?

Enviar todo ao seu servidor VPN pode describir dúas regras moi diferentes. Unha cambia o enderezo de destino e conserva o porto de entrada; a outra tamén reescribe o porto cara a un único oínte. A exposición non é a mesma, e a decisión depende de tres condicións, non da etiqueta que use a interface do router.

Condición unha: que campos cambia a regra?

A tradución do enderezo de destino e a tradución do porto de destino son operacións separadas. Unha regra pode realizar só a primeira ou ambas á vez, e a diferenza decide que servizos do host de destino son accesibles. A maioría das interfaces de fabricantes agochan esa elección tras unha soa etiqueta. Ler a regra subxacente é a única forma de saber cal obtivo.

Lea a regra real, non a etiqueta do menú. Unha pantalla que di DMZ ou todos os portos describe unha intención, non unha ruta de paquetes. A documentación de Netfilter NAT separa as dúas traducións, e ese é o modelo mental correcto aínda cando o router que ten diante é un aparello doméstico.

Dous campos, dúas preguntas diferentes.

Condición dúas: que escoita nos portos conservados?

Se a regra conserva o porto de entrada, cada porto que chega entrégase ao mesmo número do host VPN, suxeito á política de entrada dese host. Iso inclúe servizos que quizais esqueceu que estaban escoitando. A regra non creou eses servizos, e agora é o camiño cara a eles.

Se a regra reescribe o porto, ocorre o contrario: moitos portos externos colápsanse nun só oínte, e nada máis do host é accesible por esa regra. Unha reescritura de porto fixo non se converte en acceso a todos os servizos locais só porque encaixou un rango amplo de portos externos. Os dous deseños fallan en direccións distintas, e o modo de fallo é o que vostede elixe. Escolla aquel co cuxo fallo poida convivir.

Inventaríe o oínte antes de escoller.

Condición tres: que anchura ten a entrada exterior?

Publicar un só porto seleccionado é máis estreito que publicar un rango, e ambos son máis estreitos que aceptalo todo. A anchura exterior e a tradución interior son eleccións independentes, e a maior parte da confusión vén de cambiar unha mentres se describe a outra.

Para unha entrada VPN corrente, publique o transporte e o oínte que o deseño realmente necesita. Despois revise tres cousas máis: o mapeo efectivo do router, as regras de entrada propias do host de destino e se un oínte IPv6 publica o mesmo servizo. Unha regra que parece estreita nunha familia de enderezos pode ser ampla na outra.

Escriba o punto final traducido completo: protocolo, porto exterior, enderezo interior, porto interior.

O que non lle dá ningunha das dúas regras

Ningún dos dous deseños demostra que o servizo estea libre de vulnerabilidades, e ningún protexe a dispoñibilidade. A autenticación, as actualizacións e a recuperación seguen dentro do alcance por moi estreito que sexa o mapeo de portos. Un mapeo estreito reduce a superficie accesible; non fai seguro o oínte.

Unha regra ampla que xa sostén outro servizo lexítimo é unha dependencia, non só un erro. Inventaríea e substitúaa a través do seu propietario antes de retirala, ou o cambio parecerá unha caída causada por unha corrección de seguridade. A mesma precaución se aplica a unha reescritura de porto fixo da que algo máis depende en silencio.

A análise de exposición trata de que pode chegar a que, non da etiqueta na pantalla.

Decida co punto final traducido na man

Escriba o resultado da regra como unha frase: o porto UDP público X chega ao enderezo Y porto Z. Logo pregunte que servizos en Y poden responder en Z e quen é o seu dono.

nft list ruleset

Se a resposta é o único oínte que pretendía, a regra cumpre a súa función.

Se a resposta son varios, escolleu envío a todo o host, tanto se a interface o chamou así como se non.