De acordo com várias fontes (por exemplo, https://stackoverflow.com/questions/11719572/how-to-simulate-different-nat-behaviours ), MASQUERADE
o iptables se comporta como um NAT simétrico (ou seja, mapeamento dependente de endpoint e comportamento de filtragem dependente de endpoint).
Eu configurei o NAT em uma caixa Linux da seguinte maneira:
sysctl net.ipv4.ip_forward=1
iptables -A FORWARD -i enp7s0 -o enp1s0 -j ACCEPT
iptables -A FORWARD -m conntrack --ctstate related,established -j ACCEPT
iptables -t nat -A POSTROUTING -s 10.1.1.0/24 -o enp1s0 -j MASQUERADE
( enp7s0
é a interface LAN, 10.1.1.0/24
é a sub-rede LAN, enp1s0
é a interface WAN)
Em seguida, executo um teste de comportamento NAT (em outro sistema na rede interna) usando STUN:
$ turnutils_natdiscovery stunserver2024.stunprotocol.org -m
-= Mapping Behavior Discovery =-
========================================
RFC 5780 response 1
No ALG: Mapped == XOR-Mapped
0: (1892021): INFO: IPv4. Response origin: : 3.132.228.249:3478
0: (1892021): INFO: IPv4. Other addr: : 3.135.212.85:3479
0: (1892021): INFO: IPv4. UDP reflexive addr: 1.2.3.4:58197
0: (1892021): INFO: IPv4. Local addr: : 0.0.0.0:58197
========================================
RFC 5780 response 2
No ALG: Mapped == XOR-Mapped
0: (1892021): INFO: IPv4. Response origin: : 3.135.212.85:3478
0: (1892021): INFO: IPv4. Other addr: : 3.132.228.249:3479
0: (1892021): INFO: IPv4. UDP reflexive addr: 1.2.3.4:58197
0: (1892021): INFO: IPv4. Local addr: : 0.0.0.0:58197
========================================
NAT with Endpoint Independent Mapping!
========================================
$ turnutils_natdiscovery stunserver2024.stunprotocol.org -f
-= Filtering Behavior Discovery =-
========================================
RFC 5780 response 1
No ALG: Mapped == XOR-Mapped
0: (1892024): INFO: IPv4. Response origin: : 3.132.228.249:3478
0: (1892024): INFO: IPv4. Other addr: : 3.135.212.85:3479
0: (1892024): INFO: IPv4. UDP reflexive addr: 1.2.3.4:34370
0: (1892024): INFO: IPv4. Local addr: : 0.0.0.0:34370
STUN receive timeout..
STUN receive timeout..
========================================
NAT with Address and Port Dependent Filtering!
========================================
Como você pode ver, o mapeamento é independente de endpoint, portanto, seria um NAT Cone com restrição de porta, de acordo com a terminologia antiga.
Só para ter certeza, testei com o OPNsense, e o utilitário de teste detectou um NAT simétrico corretamente.
A questão é: por que minhas descobertas são diferentes das informações que encontro online? Existe uma maneira de ter NAT simétrico no Linux?
No exemplo de NAT simétrico da pergunta vinculada:
Para
-j MASQUERADE
, é o--random
que o torna NAT simétrico. Basicamente, STUN deve ver o dispositivo de firewall usando uma porta de origem diferente do cliente.Há mais alguns exemplos e explicações nas respostas aqui: https://networkengineering.stackexchange.com/a/67221/19702