Temos um servidor [S]SRV_GATEWAY com dois NICs ( [I]WAN/INT_LAN e [I]PRIV_LAN ) configurados como GATEWAY, DNS e DHCP para uma rede privada ( [N]PRIV_LAN ).
O servidor [S]SRV_GATEWAY acessa a internet (consome-se como DNS) e todos os outros servidores ( [S]PRIV_SRV_X ) consomem o DHCP, DNS e GATEWAY fornecidos pelo servidor [S]SRV_GATEWAY .
- Disposição da rede...
[N]WAN/INT_LAN (10.2.0.0/24)
↕
[I]WAN/INT_LAN
[S]SRV_GATEWAY
[I]PRIV_LAN
↕
[N]PRIV_LAN (10.3.0.0/24)
↕
...............................
↕ ↕ ↕
[S]PRIV_SRV_0 [S]PRIV_SRV_1 [S]PRIV_SRV_0
[S]PRIV_SRV_2 [S]PRIV_SRV_0
[S]PRIV_SRV_3
_ [N] - Network;
_ [I] - Network Interface;
_ [S] - Server.
_ [N]WAN/INT_LAN - Has internet access;
_ [N]PRIV_LAN - Private network.
PERGUNTA: Por que podemos ping
servidores com sucesso na internet e não podemos acessar os mesmos servidores usando curl
o servidor [S]PRIV_SRV_0 (veja a saída abaixo)?
[root@okd4-bootstrap core]# ping -c 2 www.google.com
PING www.google.com (172.217.18.196) 56(84) bytes of data.
64 bytes from ham02s14-in-f196.1e100.net (172.217.18.196): icmp_seq=1 ttl=113 time=10.5 ms
64 bytes from par10s38-in-f4.1e100.net (172.217.18.196): icmp_seq=2 ttl=113 time=10.6 ms
--- www.google.com ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.500/10.548/10.597/0.048 ms
[root@okd4-bootstrap core]# curl http://www.google.com
curl: (7) Failed to connect to www.google.com port 80: No route to host
EXTRA:
- Como SRV_GATEWAY foi definido como GATEWAY:
O servidor SRV_GATEWAY foi configurado como GATEWAY através de comandos...
Ativar encaminhamento de IP ...
tee "/etc/sysctl.d/ip_forward.conf" << EOF
net.ipv4.ip_forward=1
EOF
sysctl -w net.ipv4.ip_forward=1
Configure um gateway NAT de saída com destino nos dispositivos de mascaramento NIC ens3 ( [I]WAN/INT_LAN ) configurados no CIDR 10.3.0.0/24...
firewall-cmd --permanent --direct --passthrough ipv4 -t nat -I POSTROUTING -o ens3 -j MASQUERADE -s 10.3.0.0/24
firewall-cmd --reload
- Algumas informações obtidas do servidor [S]PRIV_SRV_0 :
[root@okd4-bootstrap core]# cat /etc/resolv.conf | grep -i '^nameserver' | head -n1 | cut -d ' ' -f2
10.3.0.14
[root@okd4-bootstrap core]# ip r
default via 10.3.0.14 dev ens3 proto dhcp metric 100
10.3.0.0/24 dev ens3 proto kernel scope link src 10.3.0.4 metric 100
[root@okd4-bootstrap core]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 10.3.0.14 0.0.0.0 UG 100 0 0 ens3
10.3.0.0 0.0.0.0 255.255.255.0 U 100 0 0 ens3
[root@okd4-bootstrap core]# netstat -r -n
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 10.3.0.14 0.0.0.0 UG 0 0 0 ens3
10.3.0.0 0.0.0.0 255.255.255.0 U 0 0 0 ens3
[root@okd4-bootstrap core]# ping -c 2 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=113 time=10.8 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=113 time=11.0 ms
--- 8.8.8.8 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 10.769/10.891/11.013/0.122 ms
[root@okd4-bootstrap core]# cat /etc/resolv.conf
# This is /run/systemd/resolve/resolv.conf managed by man:systemd-resolved(8).
# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients directly to
# all known uplink DNS servers. This file lists all configured search domains.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.
nameserver 10.3.0.14
search okd.local
[root@okd4-bootstrap core]# tracepath 8.8.8.8
1?: [LOCALHOST] pmtu 1500
1: api-int.mbr.okd.local 0.526ms
1: api-int.mbr.okd.local 0.855ms
2: okd4-services.okd.local 1.842ms !H
Resume: pmtu 1500
[root@okd4-bootstrap core]# tracepath www.google.com
1?: [LOCALHOST] pmtu 1500
1: api.mbr.okd.local 0.481ms
1: api-int.mbr.okd.local 0.562ms
2: api.mbr.okd.local 0.553ms !H
Resume: pmtu 1500
[root@okd4-bootstrap core]# ip route show
default via 10.3.0.14 dev ens3 proto dhcp metric 100
10.3.0.0/24 dev ens3 proto kernel scope link src 10.3.0.4 metric 100
[root@okd4-bootstrap core]# nslookup www.google.com
Server: 10.3.0.14
Address: 10.3.0.14#53
Non-authoritative answer:
Name: www.google.com
Address: 172.217.18.196
Name: www.google.com
Address: 2a00:1450:4007:805::2004
[root@okd4-bootstrap core]# cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
Obrigado! =D
Como apontado por @ user1686...
... estavam faltando regras sobre FORWARD .
Porém fora isso, foi necessário adicionar/habilitar a regra de mascarada .
SOLUÇÃO COMPLETA:
Ativar encaminhamento de IP...
Adicionar regras ao firewall ( firewall-cmd )...
Modelo
Exemplo
IMPORTANTE: Vários exemplos na internet recomendam colocar as interfaces [WAN_NIC] e [LAN_NIC] em zonas diferentes ( externa e interna ) conforme mostrado aqui...
... , no entanto, não quero me preocupar com zonas, pois todas as minhas regras de firewall estão na zona pública padrão . Assim, não é necessário definir zonas para que este esquema funcione, tudo pode ser deixado na zona pública .
Obrigado! =D
[Ref(s): https://www.server-world.info/en/note?os=CentOS_Stream_8&p=firewalld&f=2 , https://www.comdivision.com/blog/centos-7-nat-router -basic-configuration , https://blog.redbranch.net/2015/07/30/centos-7-as-nat-gateway-for-private-network/ . https://unix.stackexchange.com/a/550064/61742 , https://forums.centos.org/viewtopic.php?t=53819#p227743 , https://www.server-world.info/en/ note?os=CentOS_7&p=firewalld&f=2 , https://serverfault.com/q/870902/276753 ]