Por que todo mundo usa MASQUERADE/SNAT em vez de NAPT/PAT?

Se o destino puder rotear seu tráfego para a origem, nenhum NAT ou PAT será necessário.

Como exemplo, nenhum NAT/PAT é necessário se os clientes VPN em 10.8.0.0/24 quiserem conversar com seus dispositivos LAN em 192.168.1.0/24, desde que os dispositivos envolvidos possam rotear para a outra rede (através de seu gateway ).

Quando a origem está em uma rede rfc1918 (IP privado) e o destino é um IP público, porque as redes rfc1918 não são roteáveis ​​pela Internet, é necessário um NAT para substituir o IP privado pelo IP público. Esta é a tradução do endereço de origem. Este trabalho pode ser feito por um SNAT, não por um PAT.

Além disso, você está errado assumindo que SNAT/MASQUERADE não altera as portas de origem.

A opção --to-source é usada para especificar qual fonte o pacote deve usar. Esta opção, na sua forma mais simples, pega um endereço IP que queremos usar para o endereço IP de origem no cabeçalho IP. Se quisermos equilibrar vários endereços IP, podemos usar um intervalo de endereços IP, separados por um hífen. Os números de IP --to--source poderiam então, por exemplo, ser algo como no exemplo acima: 194.236.50.155-194.236.50.160. O IP de origem para cada fluxo que abrimos seria alocado aleatoriamente a partir deles, e um único fluxo sempre usaria o mesmo endereço IP para todos os pacotes nesse fluxo. Também podemos especificar um intervalo de portas a serem usadas pelo SNAT. Todas as portas de origem seriam então confinadas às portas especificadas. O bit de porta da regra seria semelhante ao exemplo acima, :1024-32000.O iptables sempre tentará evitar fazer qualquer alteração de porta se possível, mas se dois hosts tentarem usar as mesmas portas, o iptables irá mapear um deles para outra porta . Se nenhum intervalo de porta for especificado, se necessário, todas as portas de origem abaixo de 512 serão mapeadas para outras portas abaixo de 512. Aquelas entre as portas de origem 512 e 1023 serão mapeadas para portas abaixo de 1024. Todas as outras portas serão mapeadas para 1024 ou superior. Como dito anteriormente, o iptables sempre tentará manter as portas de origem usadas pela estação de trabalho real que está fazendo a conexão. Observe que isso não tem nada a ver com portas de destino, portanto, se um cliente tentar entrar em contato com um servidor HTTP fora do firewall, ele não será mapeado para a porta de controle FTP.

https://www.frozentux.net/iptables-tutorial/iptables-tutorial.html#SNATTARGET

Observe que, se seu dispositivo deseja acessar um servidor remoto em uma determinada porta de destino, há chances de que o sistema operacional já tenha atribuído uma porta de origem aleatória acima de 1024. Alcançar um servidor HTTPS remoto na porta 443 não envolve que a porta de origem seja 443.

Você tem de alguma forma a distinção errada entre SNAT/MASQUERADEe NAPT/PAT. Não está lá.

No Linux, existem dois tipos de regras NAT dinâmicas, as quais você chama de "NAPT":

• NAT de origem, que pretende deixar o endereço de destino intacto e alterar apenas o endereço de origem . Às vezes, também altera a porta de origem. Por exemplo, se a tabela de rastreamento de conexão já contém o registro com esta tupla específica (proto, src-addr, src-port, dst-addr, dst-port) (src-addr e src-port estão após a tradução), a ser capaz de fazer uma distinção qual é qual, a nova tradução deve usar outra src-port (porque este é o único grau de liberdade), então o "NAPT" inevitavelmente ocorrerá. Os exemplos de regras do tipo SNAT são SNATe MASQUERADE. A diferença entre eles é que com o SNAT você é obrigado a especificar na regrapara qual endereço traduzir (e, provavelmente, qual intervalo de portas usar), enquanto com o MASQUERADE ele faz a própria escolha, com base em qual interface o pacote está destinado a sair. Ambos devem ser instalados na POSTROUTINGcadeia, após a maioria dos outros processamentos terem sido realizados, incluindo o roteamento do pacote. Este tipo de regra é usado para permitir que muitos computadores fiquem ocultos atrás de um único endereço IP de saída, por exemplo, para acessar a Internet para a LAN e assim por diante. Isso inclui qualquer usuário de VPN também, se você pretende acessar a Internet via VPN.
• NAT de destino, que deixa o endereço de origem como estava e só atualiza o endereço de destino e, se você configurou isso, a porta de destino, então essa é a regra "NAPT" também. Regras desse tipo são DNAT, REDIRECT, CLUSTERIPe provavelmente algumas outras, não me lembro de todas; estes são instalados em PREROUTINGcadeia, porque a decisão de roteamento geralmente deve ser alterada sob a influência da regra. O pacote que originalmente se destinava à própria máquina (tem seu endereço como destino) e deveria ser percorrido INPUTe alcançado algum processo local, está sendo traduzido e, após percorrerFORWARDchain ele está sendo encaminhado para algum outro sistema. Ou vice-versa. Para onde ir, INPUT ou FORWARD, é a decisão de roteamento que devemos alterar com a regra. Este tipo de regra é utilizado para fazer o acesso a algum sistema interno a partir da Internet.

Às vezes, a propósito, ambas as regras podem ser usadas para um único pacote (e conexão). Este é o caso especial, mas útil se você precisar que os pacotes de algum sistema externo (portanto, o DNAT deve ser usado no PREROUTING) apareçam como vindos de algum endereço interno (para o qual o SNAT é usado no POSTROUTING).

No Linux também existem as regras estáticas do tipo NAT, NETMAPque são bastante especiais e raramente usadas. Duvido que você esteja falando sobre isso e que tenha visto algum howto que mencione esse tipo de regra.

O Linux não faz absolutamente nenhuma distinção entre endereços privados (RFC1918) e públicos. Você pode NAT em sua sub-rede pública se quiser (mas isso será um desperdício de endereços). Você pode deixar IPs privados sem tradução (mas geralmente isso não levará à conectividade com a Internet para eles).

A VPN nada mais é do que interface de rede adicional na máquina e deve ser tratada como tal. Consequentemente, você tem permissão para usar endereços públicos para VPN, se os tiver. Por exemplo, eu posso ter alguma sub-rede /29 roteada pelo roteador VPN e configurar o OpenVPN para que toda essa sub-rede pública seja minha rede VPN! Embora o exemplo do OpenVPN pareça artificial, é muito mais provável que o WireGuard seja configurado assim. Por exemplo, a nova solução de namespace permite que o wireguard seja a única interface no sistema. Se houver um requisito para que o sistema tenha diretamente um IP público (não discutirei os motivos pelos quais esse requisito pode vir), é inevitável que você acabe usando IPs públicos dentro da VPN! Muito provavelmente, sem nenhum NAT para eles.