No momento, estou tentando resolver o seguinte problema, mas minhas pesquisas no Google/SO não produziram um cenário correspondente até agora:

Do meu host Linux, devo alcançar o host de destino 172.19.28.152. No entanto, devido a complicações de rede corporativa, devo usar um endereço IP diferente para esse alvo: 10.187.19.132.

Preciso resolver o problema na camada IP porque o aplicativo não permite alterar o alvo (ele sempre usará o endereço IP 172..., e não há como eu alterar esse comportamento no meu cenário). Além disso, o aplicativo não me permite especificar um nome DNS em vez disso.

Por isso, quero configurar o nftables para fazer o seguinte:

Se um pacote deixar meu próprio host com o destino 172.19.28.152, substitua o IP de destino por 10.187.19.132. Quando o destino responder, reescreva 10.187.19.132 com o original 172.19.28.152 (NAT) Meu problema é que não consigo descobrir a sintaxe para tal regra.

Eu tenho um servidor Debian 12 (IP público 85.xxx.xxx.xxxem enp6s0) executando vários contêineres LXC em uma ponte de rede cbr0.

Como o IP público é dinâmico, tive que configurar forward+ preroutingregras dnatpara que as solicitações recebidas chegassem aos contêineres. Por exemplo. a porta 80/443 é atribuída ao contêiner 10.10.0.1. Aqui estão minhas nftablesregras:

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority 0; policy drop;

    ct state {established, related} accept
    iifname lo accept
    iifname cbr0 accept
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
  }
  chain forward {
    type filter hook forward priority 0; policy accept;
  }
  chain output {
    type filter hook output priority 0;
  }
}

table ip filter {
  chain forward {
    type filter hook forward priority 0; policy drop;

    oifname enp6s0 iifname cbr0 accept
    iifname enp6s0 oifname cbr0 ct state related, established accept
    # Webproxy
    iifname enp6s0 oifname cbr0 tcp dport 80 accept
    iifname enp6s0 oifname cbr0 udp dport 80 accept
    iifname enp6s0 oifname cbr0 tcp dport 443 accept
    iifname enp6s0 oifname cbr0 udp dport 443 accept
  }
}

table ip nat {

  chain postrouting {
    type nat hook postrouting priority 100; policy accept;
  }

  chain prerouting {
    type nat hook prerouting priority -100; policy accept;
    # Webproxy
    iifname enp6s0 tcp dport 80 dnat to 10.10.0.1:80
    iifname enp6s0 udp dport 80 dnat to 10.10.0.1:80
    iifname enp6s0 tcp dport 443 dnat to 10.10.0.1:443
    iifname enp6s0 udp dport 443 dnat to 10.10.0.1:443
  }

}

Agora o problema é: NAT hairpin. Tenho vários contêineres hospedando sites e às vezes acontece que alguns deles precisam se comunicar com outros contêineres usando nomes de domínio. Quando eles executam uma consulta DNS para esses domínios, eles obtêm o IP do host e a comunicação falha:

Como posso corrigir esta situação sem recorrer a hacks de DNS ? Existe uma maneira de configurar nftableso encaminhamento de solicitação internamente enquanto se tem um IP dinâmico? Como o iifnameacima brinca com isso?

Obrigado.

Digamos que eu tenha um layout de rede semelhante a este:

O que eu preciso no ?nó para que todos os PCs não sejam detectáveis ​​da rede principal, mas possam acessar a rede/internet principal? Não sei se a "Rede principal" é uma sub-rede em si ou não. A rede principal deve ver apenas o equivalente a um endereço IP, mascarando todo o tráfego como se apenas um IP estivesse sendo usado. Fui informado de que usar um roteador de sub-rede (NAT?) Ainda pode tornar as máquinas de rede detectáveis?

Existe alguma solução definitiva para isso? Posso usar hardware personalizado ou outra máquina com uma placa de rede. Sinto muito pelo meu baixo conhecimento de rede se esta for uma configuração simples.

Resumo

Eu tenho um PLC que tem um IP estático que não posso alterar e um gateway que não pode ser configurado. Eu preciso ser capaz de falar com o PLC sobre TCP na minha rede corporativa. Parece ser um bom candidato para NAT...

Cenário

Adicionei um roteador TC-Link ER605 na frente do PLC com uma rede correspondente à rede do PLC (192.168.1.1/24) e configurei a WAN para uma sub-rede na minha rede (10.15.70.19/ 24). Eu criei uma regra NAT (servidor virtual) mostrada abaixo.

Quando tento conectar ao PLC do lado da WAN (10.15.70.19:502), ele expira.

Quando estou conectado ao lado da LAN, posso abrir uma conexão para 192.168.1.88:502 sem problemas.

Problema potencial

Acho que o problema é que os pacotes podem chegar ao CP, mas o CP não tem gateway e não sabe para onde enviar os pacotes de volta. Confirmei isso substituindo o PLC por um laptop e executando o Wireshark. Não tenho certeza do que mais tentar aqui.

Qualquer ajuda ou insight em minhas suposições seria apreciada.

Ao testar um POC Zscaler (de uma perspectiva de segurança), tive dificuldade em entender como o CGNAT é roteado no cliente.

Minha principal preocupação (e pergunta) é que a rota 100.64.xy não está na tabela de roteamento (Windows 10). O gateway padrão está no meu gateway de rede local para que o tráfego também não possa ir para lá.

O que há de especial em como o tráfego CGNAT é roteado?

A tabela de roteamento no cliente é

Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0     192.168.43.1   192.168.43.107     50
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    331
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    331
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    331
     172.22.208.0    255.255.240.0         On-link      172.22.208.1    271
     172.22.208.1  255.255.255.255         On-link      172.22.208.1    271
   172.22.223.255  255.255.255.255         On-link      172.22.208.1    271
     192.168.43.0    255.255.255.0         On-link    192.168.43.107    306
   192.168.43.107  255.255.255.255         On-link    192.168.43.107    306
   192.168.43.255  255.255.255.255         On-link    192.168.43.107    306
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    331
        224.0.0.0        240.0.0.0         On-link    192.168.43.107    306
        224.0.0.0        240.0.0.0         On-link      172.22.208.1    271
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    331
  255.255.255.255  255.255.255.255         On-link    192.168.43.107    306
  255.255.255.255  255.255.255.255         On-link      172.22.208.1    271

Abaixo está a resolução de um serviço corporativo interno que está configurado no zscaler (e, portanto, roteado pelo CGNAT). O mesmo nome fora do zscaler aponta para um endereço RFC1918 clássico.

> nslookup internalcorporatesite.com
Server:  xxx.com
Address:  192.168.43.1

Non-authoritative answer:
Name:    internalcorporatesite.com
Address:  100.64.1.9

Observe que o gateway padrão 192.168.43.1não tem conhecimento do CGNAT - é uma rede local e o CGNAT é usado pelo zscaler.

Existem muitos avisos sobre redes NAT duplas.

DSL---modem with router-----second router
      configured by ISP     inner network
        first NAT            second NAT

O que exatamente quebrará em uma rede NAT dupla?

TL;DR: Como posso obter o IP do cliente conectado a um VPS hospedado remotamente para ser o IP que é encaminhado/natted, via iptables, para um servidor de jogos rodando em minha casa?

Eu tenho um servidor de jogos Rust que estou hospedando em minha casa. Eu quero que isso seja público, mas não quero necessariamente dar meu endereço IP para todos. Então estou alugando um pequeno VPS que pretendo usar basicamente como proxy reverso. Atualmente, estou usando o nginx para encaminhar o tráfego por uma VPN de servidor clinet, que funciona bem. No entanto, no servidor do jogo, o IP de cada jogador é o endereço do túnel do VPS, não o IP do cliente real. Eu tentei usar proxy_pass $remote_addr:28015 transparancy; proxy_responses 0na minha configuração do nginx, nenhuma alteração. Então eu mudei para fazê-lo via iptables.

Eu posso fazer funcionar 99% do jeito que eu quero, fazendo exatamente isso:

sysctl net.ipv4.ip_forward=1
iptables -t nat -A PREROUTING -p tcp --dport 28015 -j NAT --to-destination my_ip:28015
iptables -t nat -A PREROUTING -p udp --dport 28015 -j NAT --to-destination my_ip:28015
iptables -t nat -A PREROUTING -p tcp --dport 28016 -j NAT --to-destination my_ip:28016
iptables -t nat -A PREROUTING -p udp --dport 28016 -j NAT --to-destination my_ip:28016
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -p tcp -d my_ip --dport 28015 -m state --state NOVO, ESTABELECIDO, RELACIONADO -j ACEITAR
iptables -A FORWARD -p ucp -d my_ip --dport 28015 -m state --state NOVO, ESTABELECIDO, RELACIONADO -j ACEITAR
ufw desativar
ufw ativar
vps reboot \

O que isso faz é basicamente o mesmo que o nginx, onde funciona bem, mas todos têm apenas o ip público do VPS (observe que a LAN e o endereço IP público do VPS são os mesmos). Se eu omitir a máscara, não funciona.

Algumas informações sobre a configuração:
VPS tem uma única interface: eth0
VPS está rodando Ubuntu 20.04
Na minha casa, o modem está em modo passthru para pfsesne. No pfsense, tenho regras de encaminhamento de porta para passar 28015/28016 tcp/udp para gameserver.

Nota lateral: não sei por que o nginx não funcionou para isso. Era quase como se o nginx não estivesse fazendo nada com a proxy_pass $remote_addrdiretiva.

Na AWS temos 3 instâncias na mesma sub-rede/VPC. Gostaríamos que a instância do cliente fizesse uma solicitação de DNS para uma segunda instância de análise, que encaminhará a solicitação para uma terceira instância executando um serviço de DNS. O serviço DNS deve então fornecer uma resposta à instância de análise, que deve então responder ao cliente.

O objetivo é que a instância Analysis possa interceptar o tráfego entre as instâncias Client e DNS para fins de análise.

Instância de cliente -> Instância de análise (NAT) -> Instância de DNS

A configuração atual permite que a instância do cliente envie uma solicitação de DNS por meio da instância de análise para a instância de DNS. A instância do DNS responde à instância do Analysis, tcpdumpmas a instância Client nunca recebe uma resposta da instância do Analysis.

Temos as verificações de origem/destino na AWS para a instância de análise que executa NAT desativadas.

Primeiro, ativamos o encaminhamento na instância do Analysis:

sudo sysctl -w net.ipv4.ip_forward=1

Em seguida, adicionamos as seguintes regras IPTables à instância Analysis

sudo iptables -A FORWARD -p udp --dport 53 -d 192.168.1.151 -j ACCEPT
sudo iptables -t nat -A PREROUTING -p udp --dport 53 -j DNAT --to-destination 192.168.1.151
sudo iptables -t nat -A POSTROUTING -d 192.168.1.151 -s 192.168.1.156 -p udp --dport 53 -j SNAT --to 192.168.1.213

Outras POSTROUTINGregras, como as seguintes, também foram tentadas

sudo iptables -t nat -A POSTROUTING -j MASQUERADE
sudo iptables -t nat -A POSTROUTING -p udp -d 192.168.1.151 --dport 53 -j SNAT --to-source 192.168.1.213
sudo iptables -t nat -A POSTROUTING -p udp -d 192.168.1.151 --dport 53 -j MASQUERADE

Todos com o mesmo resultado, a instância Client nunca recebe uma resposta DNS. Pensamentos sobre o que pode estar impedindo a instância de análise de retornar uma resposta?

Muitas vezes vejo que existem algumas regras de correspondência de estado em uma cadeia de iptables, como INPUT.

Eu sei o que eles estão fazendo, e estou interessado nisso

Devo fazer o mesmo para as chains da tabela NAT?

Por exemplo, no meu roteador doméstico, quero que ele aceite ssh e também atue como um roteador NAT.

Se tiver-mos:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

-A INPUT -p tcp -m state --state NEW -m tcp --dport 22 -j ACCEPT

devo fazer segue para um melhor desempenho?

-t nat -A POSTROUTING -m state --state RELATED,ESTABLISHED -j MASQUERADE

-t nat -A POSTROUTING -s 192.168.1.0/24 -o wan0 -m state --state NEW -j MASQUERADE

Acho que NÃO devo fazer o mesmo para a cadeia POSTROUTING, mas sim para o FORWARD.

Obrigado!

História

Eu tenho uma interface virtual VPN wireguard wg0(pode ser qualquer outra coisa) e uma interface física eth0. Desejo rotear pacotes da VPN para minha LAN ou de uma interface para outra interface.

Quase todos os blogs, artigos, tutoriais aconselham usando MASQUERADEou Source NATapenas:iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Além disso, IP masqueradeé simplesmente um SNAT (Source NAT), não altera a porta de origem.

Pergunta

• Estou errado em pensar que deveria usar um NAPT/PAT em vez disso?
• Para completar, como posso adicionar uma regra NAPT/PAT com iptables e/ou nftables?

Pensamentos

Pode haver conflitos (porta de origem) entre os pacotes gerados pelo host e encaminhados de wg0(ou qualquer outra interface virtual/física). IMHO NAPT deve ser usado para evitar esses conflitos.

RFC 2663, Tradução de porta de endereço de rede (NAPT)