Aqui está o problema que estou tentando resolver. Existe um servidor ("sistema remoto") no qual posso fazer o ssh no meu computador local, mas esse sistema remoto não possui conexão à Internet. Desejo fornecer ao sistema remoto acesso à Internet através do meu computador local usando VPN baseada em ssh. Como eu faço isso? Eu tentei o seguinte, que parece funcionar parcialmente. O que quero dizer com 'trabalho parcialmente' é que os pacotes de conexão (pacotes de sincronização) são enviados para o meu computador local, mas não conseguem estabelecer a conexão com a Internet. Estou usando o tcpdump para capturar pacotes no computador local. O computador local e o sistema remoto estão executando o centos 7.
A configuração - Nota: os comandos abaixo são executados em ordem. Os comandos user @ remote são executados no servidor remoto e os comandos user @ local são executados no computador local.
[usuário @ remoto ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
host do escopo inet 127.0.0.1/8 lo
valid_lft forever preferência_lft forever
host do escopo inet6 :: 1/128
valid_lft forever preferência_lft forever
2: eth0: mtu 1500 qdisc estado pfifo_fast UP qlen 1000
link / éter AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
escopo AAA.BBB.CCC.DDD / 24d AAA.BBB.CCC.255 escopo dinâmico global eth0
valid_lft 1785sec preferido_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: dinâmica global do noprefixroute do escopo LLLL / 64
valid_lft 2591987sec preferido_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: link do escopo LLLL / 64
valid_lft forever preferência_lft forever
[usuário @ local ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
host do escopo inet 127.0.0.1/8 lo
valid_lft forever preferência_lft forever
host do escopo inet6 :: 1/128
valid_lft forever preferência_lft forever
2: eth0: mtu 1500 qdisc estado pfifo_fast UP qlen 1000
link / éter AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
escopo AAA.BBB.CCC.DDD / 24d AAA.BBB.CCC.255 escopo dinâmico global eth0
valid_lft 1785sec preferido_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: dinâmica global do noprefixroute do escopo LLLL / 64
valid_lft 2591987sec preferido_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: link do escopo LLLL / 64
valid_lft forever preferência_lft forever
Crie a interface tun0 no sistema remoto .
[user @ remote ~] $ sudo ip tuntap adiciona o modo tun0 tun
[usuário @ remoto ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
host do escopo inet 127.0.0.1/8 lo
valid_lft forever preferência_lft forever
host do escopo inet6 :: 1/128
valid_lft forever preferência_lft forever
2: eth0: mtu 1500 qdisc estado pfifo_fast UP qlen 1000
link / éter AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
escopo AAA.BBB.CCC.DDD / 24d AAA.BBB.CCC.255 escopo dinâmico global eth0
valid_lft 1785sec preferido_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: dinâmica global do noprefixroute do escopo LLLL / 64
valid_lft 2591987sec preferido_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: link do escopo LLLL / 64
valid_lft forever preferência_lft forever
3: tun0: mtu 1500 qdisc noop state DOWN qlen 500
link / nenhum
Crie a interface tun0 no sistema local .
[usuário @ local ~] $ sudo ip tuntap add tun0 mode tun
[usuário @ local ~] $ ip addr show
1: lo: mtu 65536 qdisc noqueue state UNKNOWN
link / loopback 00: 00: 00: 00: 00: 00 brd 00: 00: 00: 00: 00: 00
host do escopo inet 127.0.0.1/8 lo
valid_lft forever preferência_lft forever
host do escopo inet6 :: 1/128
valid_lft forever preferência_lft forever
2: eth0: mtu 1500 qdisc estado pfifo_fast UP qlen 1000
link / éter AA: BB: CC: DD: EE: FF brd ff: ff: ff: ff: ff: ff
escopo AAA.BBB.CCC.DDD / 24d AAA.BBB.CCC.255 escopo dinâmico global eth0
valid_lft 1785sec preferido_lft 1785sec
inet6 EEEE: FFFF: GGGG: HHHH: IIII: JJJJ: KKKK: dinâmica global do noprefixroute do escopo LLLL / 64
valid_lft 2591987sec preferido_lft 604787sec
inet6 ABCD :: IIII: JJJJ: KKKK: link do escopo LLLL / 64
valid_lft forever preferência_lft forever
3: tun0: mtu 1500 qdisc noop state DOWN qlen 500
link / nenhum
Atribua um endereço IP ao tun0 e exiba-o:
[user @ local ~] $ sudo ip addr add 10.0.2.1/30 dev tun0
[usuário @ local ~] $ sudo conjunto de links ip dev tun0 up
[usuário @ local ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc estado pfifo_fast DOWN qlen 500
link / nenhum
escopo inet 10.0.2.1/30 global tun0
valid_lft forever preferência_lft forever
[user @ remote ~] $ sudo ip addr add 10.0.2.2/30 dev tun0
[user @ remote ~] $ sudo conjunto de links ip dev tun0 up
[usuário @ remoto ~] $ ip addr show tun0
3: tun0: mtu 1500 qdisc estado pfifo_fast DOWN qlen 500
link / nenhum
inet 10.0.2.2/30 escopo global tun0
valid_lft forever preferência_lft forever
Modifique sshd_config nos sistemas remoto e local para ativar o encapsulamento:
[user @ remote ~] $ sudo grep PermTunnel / etc / ssh / sshd_config PermitTunnel ponto a ponto
[user @ local ~] $ sudo grep PermTunnel / etc / ssh / sshd_config PermitTunnel ponto a ponto
Crie o túnel ssh:
[usuário @ local ~] $ sudo ssh -f -w0: 0 root @ remote true senha do root @ remote: [usuário @ local ~] $ ps aux | grep root @ remote raiz 1851 0,0 0,0 76112 1348? Ss 23:12 0:00 ssh -f -w0: 0 root @ remote true
Teste o ping nos dois servidores usando os novos endereços IP:
[usuário @ local ~] $ ping 10.0.2.2 -c 2 PING 10.0.2.2 (10.0.2.2) 56 (84) bytes de dados. 64 bytes de 10.0.2.2: icmp_seq = 1 ttl = 64 time = 1,68 ms 64 bytes de 10.0.2.2: icmp_seq = 2 ttl = 64 time = 0.861 ms --- 10.0.2.2 estatísticas de ping --- 2 pacotes transmitidos, 2 recebidos, 0% de perda de pacotes, tempo 1002ms rtt min / avg / max / mdev = 0.861 / 1.274 / 1.688 / 0.415 ms
[user @ remote ~] $ ping 10.0.2.1 -c 2 PING 10.0.2.1 (10.0.2.1) 56 (84) bytes de dados. 64 bytes de 10.0.2.1: icmp_seq = 1 ttl = 64 time = 0.589 ms 64 bytes de 10.0.2.1: icmp_seq = 2 ttl = 64 time = 0.889 ms --- 10.0.2.1 estatísticas de ping --- 2 pacotes transmitidos, 2 recebidos, 0% de perda de pacotes, tempo 1000ms rtt min / média / máx / mdev = 0,589 / 0,739 / 0,889 / 0,150 ms
rota [user @ remote ~] $ Tabela de roteamento IP do kernel Gateway de destino Genmask Flags Ref métrico Use Iface gateway padrão 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 U 0 0 0 tun0 AAA.BBB.CCC.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 [usuário @ remoto ~] $ ip show de rota padrão via AAA.BBB.CCC.1 dev eth0 proto static metric 100 10.0.2.0/30 dev tun0 proto kernel scope link src 10.0.2.2 AAA.BBB.CCC.0 / 24 dev link do escopo do proto eth0 do kernel src AAA.BBB.CCC.31 métrica 100
Obtenha endereços IP do Google:
[usuário @ local ~] $ nslookup google.com Servidor: servidor Endereço: servidor # 53 Resposta não autorizada: Nome: google.com Endereço: 173.194.219.101 Nome: google.com Endereço: 173.194.219.100 Nome: google.com Endereço: 173.194.219.113 Nome: google.com Endereço: 173.194.219.102 Nome: google.com Endereço: 173.194.219.139 Nome: google.com Endereço: 173.194.219.138
IMPORTANTE: Executei o comando acima em um momento diferente e obtive um resultado diferente. Não assuma que sua resposta será a mesma para a pesquisa acima.
Como todos os endereços IP do Google começam em 173.194.219, vamos rotear todos esses endereços IP pelo computador local.
[user @ remote ~] $ sudo ip route add 173.194.219.0/24 dev tun0 rota [user @ remote ~] $ Tabela de roteamento IP do kernel Gateway de destino Genmask Flags Ref métrico Use Iface gateway padrão 0.0.0.0 UG 100 0 0 eth0 10.0.2.0 0.0.0.0 255.255.255.252 U 0 0 0 tun0 AAA.BBB.CCC.0 0.0.0.0 255.255.255.0 U 100 0 0 eth0 173.194.219.0 0.0.0.0 255.255.255.0 U 0 0 0 tun0 [usuário @ remoto ~] $ ip show de rota padrão via AAA.BBB.CCC.1 dev eth0 proto static metric 100 10.0.2.0/30 dev tun0 proto kernel scope link src 10.0.2.2 AAA.BBB.CCC.0 / 24 dev link do escopo do proto eth0 do kernel src AAA.BBB.CCC.31 métrica 100 173.194.219.0/24 dev tun0 scope link
Ative ip_forwarding:
[user @ local ~] $ grep ip_forward /etc/sysctl.conf net.ipv4.ip_forward = 1 [user @ local ~] reinício da rede do serviço $ sudo Reiniciando a rede (via systemctl): [OK]
Configure a captura de pacotes no computador local usando o tcpdump:
[user @ local ~] $ sudo tcpdump -nn -vv 'porta não 22' -i qualquer tcpdump: ouvindo qualquer LINUX_SLL do tipo link (preparado para Linux), tamanho de captura 65535 bytes
Tente se conectar ao google a partir do servidor remoto.
[user @ remote ~] $ openssl s_client -connect google.com:443 socket: nenhuma rota para hospedar connect: errno = 113
Assim que o comando openssl for executado no servidor remoto, o tcpdump captura alguns pacotes:
10.0.2.2.52768> 173.194.219.102.443: Flags [S], cksum 0x8702 (correto), seq 994650730, vitória 29200, opções [mss 1460, sackOK, TS val 7701438 ecr 0, nop, wscale 7], comprimento 0
00: 49: 33.247753 IP (tos 0x0, ttl 64, id 46037, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
10.0.2.2.48774> 173.194.219.100.443: Flags [S], cksum 0x47a7 (correto), seq 2218733674, win 29200, opções [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], comprimento 0
00: 49: 33.247883 IP (tos 0xc0, ttl 64, id 9538, deslocamento 0, sinalizadores [nenhum], proto ICMP (1), comprimento 88)
10.0.2.1> 10.0.2.2: host ICMP 173.194.219.100 inacessível - administrador proibido, comprimento 68
IP (tos 0x0, ttl 63, id 46037, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
10.0.2.2.48774> 173.194.219.100.443: Flags [S], cksum 0x47a7 (correto), seq 2218733674, win 29200, opções [mss 1460, sackOK, TS val 7701439 ecr 0, nop, wscale 7], comprimento 0
00: 49: 33.253068 IP (tos 0x0, ttl 64, identificação 26282, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
10.0.2.2.51312> 173.194.219.101.443: Flags [S], cksum 0x6ff8 (correto), seq 2634016105, win 29200, opções [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], comprimento 0
00: 49: 33.254771 IP (tos 0xc0, ttl 64, id 9539, deslocamento 0, sinalizadores [nenhum], proto ICMP (1), comprimento 88)
10.0.2.1> 10.0.2.2: host ICMP 173.194.219.101 inacessível - administrador proibido, comprimento 68
IP (tos 0x0, ttl 63, id 26282, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
10.0.2.2.51312> 173.194.219.101.443: Flags [S], cksum 0x6ff8 (correto), seq 2634016105, win 29200, opções [mss 1460, sackOK, TS val 7701443 ecr 0, nop, wscale 7], comprimento 0
00: 49: 33.258805 IP (tos 0x0, ttl 64, id 9293, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
10.0.2.2.33686> 173.194.219.139.443: Flags [S], cksum 0x542b (correto), seq 995927943, win 29200, opções [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], comprimento 0
00: 49: 33.258845 IP (tos 0xc0, ttl 64, id 9540, deslocamento 0, sinalizadores [nenhum], proto ICMP (1), comprimento 88)
10.0.2.1> 10.0.2.2: host ICMP 173.194.219.139 inacessível - administrador proibido, comprimento 68
IP (tos 0x0, ttl 63, id 9293, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
10.0.2.2.33686> 173.194.219.139.443: Flags [S], cksum 0x542b (correto), seq 995927943, win 29200, opções [mss 1460, sackOK, TS val 7701450 ecr 0, nop, wscale 7], comprimento 0
^ C
13 pacotes capturados
13 pacotes recebidos pelo filtro
0 pacotes descartados pelo kernel
Os pacotes capturados usando o tcpdump sugerem que é feita uma tentativa de estabelecer a conexão (os pacotes de sincronização são enviados), mas nada é recebido. Também há uma mensagem 10.0.2.1 > 10.0.2.2: ICMP host 173.194.219.139 unreachable - admin prohibited, length 68que parece sugerir um problema.
Alguma sugestão sobre como solucionar esse problema? Existem regras de iptable que precisam ser adicionadas? Qualquer problema de firewall (firewall-d?).
Nota # 1
Saída de iptables-save:
[user @ local ~] $ sudo iptables -t nat -A POSTROUTING -s 10.0.2.2/32! -d 10.0.2.1/30 -j MASQUERADE -o eth0 [usuário @ local ~] $ sudo iptables-save # Gerado por iptables-save v1.4.21 em Sat Apr 15 01:40:57 2017 * nat : PREROUTING ACCEPT [35: 8926] : ACEITA ENTRADA [1:84] : ACEITAÇÃO DE SAÍDA [6: 439] : ACEITAÇÃO PÓS-OPERATÓRIA [6: 439] : OUTPUT_direct - [0: 0] : POSTROUTING_ZONES - [0: 0] : POSTROUTING_ZONES_SOURCE - [0: 0] : POSTROUTING_direct - [0: 0] : POST_public - [0: 0] : POST_public_allow - [0: 0] : POST_public_deny - [0: 0] : POST_public_log - [0: 0] : PREROUTING_ZONES - [0: 0] : PREROUTING_ZONES_SOURCE - [0: 0] : PREROUTING_direct - [0: 0] : PRE_public - [0: 0] : PRE_public_allow - [0: 0] : PRE_public_deny - [0: 0] : PRE_public_log - [0: 0] -A PREROUTING -j PREROUTING_direct -A PREROUTING -j PREROUTING_ZONES_SOURCE -A PREROUTING -j PREROUTING_ZONES -A OUTPUT -j OUTPUT_direct -A POSTROUTING -j POSTROUTING_direct -A POSTROUTING -j POSTROUTING_ZONES_SOURCE -A POSTROUTING -j POSTROUTING_ZONES -A POSTROUTING -s 10.0.2.2/32! -d 10.0.2.0/30 -j MASQUERADE -A POSTROUTING_ZONES -o eth0 -g POST_public -A POSTROUTING_ZONES -g POST_public -A POST_public -j POST_public_log -A POST_public -j POST_public_deny -A POST_public -j POST_public_allow -A PREROUTING_ZONES -i eth0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow COMMIT # Concluído em 15 de abril, 01:40:57 2017 # Gerado por iptables-save v1.4.21 em Sat Apr 15 01:40:57 2017 * mangle : PREROUTING ACCEPT [169: 18687] : ACEITA ENTRADA [144: 11583] : ACEITO PARA A FRENTE [0: 0] : ACEITAÇÃO DE SAÍDA [80: 8149] : ACEITAÇÃO PÓS-OPERATÓRIA [80: 8149] : FORWARD_direct - [0: 0] : INPUT_direct - [0: 0] : OUTPUT_direct - [0: 0] : POSTROUTING_direct - [0: 0] : PREROUTING_ZONES - [0: 0] : PREROUTING_ZONES_SOURCE - [0: 0] : PREROUTING_direct - [0: 0] : PRE_public - [0: 0] : PRE_public_allow - [0: 0] : PRE_public_deny - [0: 0] : PRE_public_log - [0: 0] -A PREROUTING -j PREROUTING_direct -A PREROUTING -j PREROUTING_ZONES_SOURCE -A PREROUTING -j PREROUTING_ZONES -A INPUT -j INPUT_direct -A FORWARD -j FORWARD_direct -A OUTPUT -j OUTPUT_direct -A POSTROUTING -j POSTROUTING_direct -A PREROUTING_ZONES -i eth0 -g PRE_public -A PREROUTING_ZONES -g PRE_public -A PRE_public -j PRE_public_log -A PRE_public -j PRE_public_deny -A PRE_public -j PRE_public_allow COMMIT # Concluído em 15 de abril, 01:40:57 2017 # Gerado por iptables-save v1.4.21 em Sat Apr 15 01:40:57 2017 *segurança : ACEITA ENTRADA [2197: 163931] : ACEITO PARA A FRENTE [0: 0] : ACEITAÇÃO DE SAÍDA [1229: 185742] : FORWARD_direct - [0: 0] : INPUT_direct - [0: 0] : OUTPUT_direct - [0: 0] -A INPUT -j INPUT_direct -A FORWARD -j FORWARD_direct -A OUTPUT -j OUTPUT_direct COMMIT # Concluído em 15 de abril, 01:40:57 2017 # Gerado por iptables-save v1.4.21 em Sat Apr 15 01:40:57 2017 *cru : ACEITAÇÃO PREROUTING [2362: 184437] : ACEITAÇÃO DE SAÍDA [1229: 185742] : OUTPUT_direct - [0: 0] : PREROUTING_direct - [0: 0] -A PREROUTING -j PREROUTING_direct -A OUTPUT -j OUTPUT_direct COMMIT # Concluído em 15 de abril, 01:40:57 2017 # Gerado por iptables-save v1.4.21 em Sat Apr 15 01:40:57 2017 *filtro : ACEITA ENTRADA [0: 0] : ACEITO PARA A FRENTE [0: 0] : ACEITAÇÃO DE SAÍDA [80: 8149] : FORWARD_IN_ZONES - [0: 0] : FORWARD_IN_ZONES_SOURCE - [0: 0] : FORWARD_OUT_ZONES - [0: 0] : FORWARD_OUT_ZONES_SOURCE - [0: 0] : FORWARD_direct - [0: 0] : FWDI_public - [0: 0] : FWDI_public_allow - [0: 0] : FWDI_public_deny - [0: 0] : FWDI_public_log - [0: 0] : FWDO_public - [0: 0] : FWDO_public_allow - [0: 0] : FWDO_public_deny - [0: 0] : FWDO_public_log - [0: 0] : INPUT_ZONES - [0: 0] : INPUT_ZONES_SOURCE - [0: 0] : INPUT_direct - [0: 0] : IN_public - [0: 0] : IN_public_allow - [0: 0] : IN_public_deny - [0: 0] : IN_public_log - [0: 0] : OUTPUT_direct - [0: 0] -A INPUT -m conntrack --ctstate RELACIONADO, ESTABELECIDO -j ACEITA -A ENTRADA -i lo -j ACEITA -A INPUT -j INPUT_direct -A INPUT -j INPUT_ZONES_SOURCE -A INPUT -j INPUT_ZONES -A INPUT -m conntrack --ctstate INVALID -j DROP -A INPUT -j REJECT --reject-with icmp-host-allowed -A FORWARD -m conntrack --ctstate RELACIONADO, ESTABELECIDO -j ACEITA -A FRENTE -i lo -j ACEITA -A FORWARD -j FORWARD_direct -A FORWARD -j FORWARD_IN_ZONES_SOURCE -A FORWARD -j FORWARD_IN_ZONES -A FORWARD -j FORWARD_OUT_ZONES_SOURCE -A FORWARD -j FORWARD_OUT_ZONES -A FORWARD -m conntrack --ctstate INVALID -j DROP -A FORWARD -j REJECT --reject-with icmp-host-proibido -A OUTPUT -j OUTPUT_direct -A FORWARD_IN_ZONES -i eth0 -g FWDI_public -A FORWARD_IN_ZONES -g FWDI_public -A FORWARD_OUT_ZONES -o eth0 -g FWDO_public -A FORWARD_OUT_ZONES -g FWDO_public -A FWDI_public -j FWDI_public_log -A FWDI_public -j FWDI_public_deny -A FWDI_public -j FWDI_public_allow -A FWDI_public -p icmp -j ACEITAR -A FWDO_public -j FWDO_public_log -A FWDO_public -j FWDO_public_deny -A FWDO_public -j FWDO_public_allow -A INPUT_ZONES -i eth0 -g IN_public -A INPUT_ZONES -g IN_public -A IN_public -j IN_public_log -A IN_public -j IN_public_deny -A IN_public -j IN_public_allow -A IN_public -p icmp -j ACEITAR -A IN_public_allow -p tcp -m tcp --dport 22 -m conntrack --ctstate NEW -j ACEITAR COMMIT # Concluído em 15 de abril, 01:40:57 2017
Nota 2:
Eu configurei um servidor web apache em um host separado ao qual somente o servidor local tem acesso. Executei o tcpdump no servidor da web que escuta na porta 80. Quando executo
telnet webserver 80, capturo os seguintes pacotes. Esse é o comportamento esperado, pois a conexão TCP é estabelecida (S, S-Ack, Ack).
[user @ webserver ~] $ sudo tcpdump -nn -vv 'porta não 22 e 80' -i eth0
tcpdump: escutando eth0, tipo de link EN10MB (Ethernet), tamanho da captura 65535 bytes
07: 17: 30.411474 IP (tos 0x10, ttl 64, id 34376, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
local.server.46710> web.server.80: Sinalizadores [S], cksum 0x8412 (incorreto -> 0x6d96), seq 3018586542, vitória 29200, opções [mss 1460, sackOK, TS val 3047398 ecr 0, nop, wscale 7] comprimento 0
07: 17: 30.411557 IP (tos 0x0, ttl 64, id 0, deslocamento 0, sinalizadores [DF], protocolo TCP (6), comprimento 60)
web.server.80> local.server.46710: Sinalizadores [S.], cksum 0x8412 (incorreto -> 0x9114), seq 2651711943, ack 3018586543, vitória 289586543, vitória 28960, opções [mss 1460, sackOK, TS val 37704524 ecr 3047398, nop , wscale 7], comprimento 0
07: 17: 30.411725 IP (tos 0x10, ttl 64, id 34377, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 52)
local.server.46710> web.server.80: Sinalizadores [.], cksum 0x840a (incorreto -> 0x301c), seq 1, ack 1, vitória 229, opções [nop, nop, TS val 3047398 ecr 37704524], comprimento 0
Quando tento conectar-me ao servidor da web a partir do servidor remoto por meio do servidor local, o tcpdump no servidor da web não captura nenhum pacote (nem mesmo a sincronização inicial), mas o servidor local captura o pacote de sincronização enviado ao servidor da web (veja abaixo). Isso me faz acreditar que algo está impedindo que os pacotes sejam enviados para o servidor da web - talvez uma configuração incorreta ou um firewall.
[user @ local ~] $ sudo tcpdump -nn -vv 'porta não 22 e 80' -i qualquer
tcpdump: ouvindo qualquer LINUX_SLL do tipo link (preparado para Linux), tamanho de captura 65535 bytes
02: 24: 09.135842 IP (tos 0x10, ttl 64, id 38062, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
10.0.2.2.50558> web.server.80: Flags [S], cksum 0x668d (correto), seq 69756226, vitória 29200, opções [mss 1460, sackOK, TS val 4780524 ecr 0, nop, wscale 7], comprimento 0
IMPORTANTE: os pacotes não estão sendo roteados através do eth0, mas, em vez disso, é feita a tentativa de enviar os pacotes ao servidor da web via tun0 (que falha). Eu posso confirmar isso executando o tcpdump na interface tun0:
[user @ local ~] $ sudo tcpdump -nn -vv 'porta não 22 e 80' -i tun0
tcpdump: escutando tun0, RAW do tipo link (IP bruto), tamanho da captura 65535 bytes
02: 28: 10.295972 IP (tos 0x10, ttl 64, id 46976, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
10.0.2.2.50560> webserver.80: Flags [S], cksum 0xd560 (correto), seq 605366388, vitória 29200, opções [mss 1460, sackOK, TS val 5021684 ecr 0, nop, wscale 7], comprimento 0
Nota 3:
desliguei o firewalld no computador local e os pacotes de sincronização foram recebidos pelo servidor da web.
[user @ local ~] $ sudo systemctl pára o firewalld
[user @ webserver ~] $ sudo tcpdump -nn -vv 'porta não 22 e 80' -i eth0
tcpdump: escutando eth0, tipo de link EN10MB (Ethernet), tamanho da captura 65535 bytes
08: 25: 17.390912 IP (tos 0x10, ttl 63, id 61767, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
10.0.2.2.50580> web.server.80: Flags [S], cksum 0x30dc (correto), seq 2601927549, vitória 29200, opções [mss 1460, sackOK, TS val 7123514 ecr 0, nop, wscale 7], comprimento 0
08: 25: 17.391003 IP (tos 0x0, ttl 64, id 0, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
web.server.80> 10.0.2.2.50580: Sinalizadores [S.], cksum 0x4e23 (incorreto -> 0xa316), seq 959115533, ack 2601927550, vitória 28960, opções de opções [mss 1460, sackOK, TS val 41771503 ecr 7123514, nop , wscale 7], comprimento 0
08: 25: 17.391192 IP (tos 0x0, ttl 128, identificação 60032, deslocamento 0, sinalizadores [nenhum], protocolo TCP (6), comprimento 40)
10.0.2.2.50580> web.server.80: Flags [R], cksum 0x7339 (correto), seq 2601927550, vitória 8192, comprimento 0
08: 25: 18.393794 IP (tos 0x10, ttl 63, id 61768, deslocamento 0, sinalizadores [DF], proto TCP (6), comprimento 60)
10.0.2.2.50580> web.server.80: Flags [S], cksum 0x2cf1 (correto), seq 2601927549, vitória 29200, opções [mss 1460, sackOK, TS val 7124517 ecr 0, nop, wscale 7], comprimento 0
08: 25: 18.393898 IP (tos 0x0, ttl 64, id 0, deslocamento 0, sinalizadores [DF], protocolo TCP (6), comprimento 60)
web.server.80> 10.0.2.2.50580: Sinalizadores [S.], cksum 0x4e23 (incorreto -> 0x7e71), seq 974785773, ack 2601927550, vitória 28960, opções [mss 1460, sackOK, TS val 41772506 ecr 7124517, nop , wscale 7], comprimento 0
08: 25: 18.394003 IP (tos 0x0, ttl 128, identificação 60033, deslocamento 0, sinalizadores [nenhum], protocolo TCP (6), comprimento 40)
10.0.2.2.50580> web.server.80: Flags [R], cksum 0x566a (correto), seq 2601927550, vitória 8192, comprimento 0
Agora, claramente, o IP de origem precisa ser atualizado para corresponder ao endereço IP do servidor local antes que o pacote seja enviado ao servidor da web. Como o @xin sugeriu, o NAT precisa ser configurado no servidor local.
Nota # 4:
Depois de tentar conectar-me ao servidor da web, vejo que a contagem de pacotes para a regra 9 aumenta 1 (como visto abaixo).
[usuário @ local ~] $ sudo iptables -nvL --line-numbers .......... Cadeia FORWARD (política ACEITE 0 pacotes, 0 bytes) num pkts bytes destino prot opt in out origem destino 1 0 0 ACEITAR tudo - * * 0.0.0.0/0 0.0.0.0/0 ctstate RELACIONADO, ESTABELECIDO 2 0 0 ACEITAR tudo - lo * 0.0.0.0/0 0.0.0.0/0 3 1 60 FORWARD_direct all - * * 0.0.0.0/0 0.0.0.0/0 4 1 60 FORWARD_IN_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0 5 1 60 FORWARD_IN_ZONES all - * * 0.0.0.0/0 0.0.0.0/0 6 1 60 FORWARD_OUT_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0 7 1 60 FORWARD_OUT_ZONES all - * * 0.0.0.0/0 0.0.0.0/0 8 0 0 DROP all - * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID 9 1 60 REJEITAR TODOS - * * 0.0.0.0/0 0.0.0.0/0 rejeitar-com icmp-host-proibido .......... [usuário @ local ~] $ sudo iptables -D FORWARD 9
Depois que a regra 9 da cadeia FORWARD é excluída (de cima, como sugerido pelo @xin), eu consigo me conectar ao servidor da web.
[usuário @ local ~] $ sudo iptables -nvL --line-numbers .......... Cadeia FORWARD (política ACEITE 1 pacotes, 60 bytes) num pkts bytes destino prot opt in out origem destino 1 12 5857 ACEITAR todos - * * 0.0.0.0/0 0.0.0.0/0 ctstate RELACIONADOS, ESTABELECIDOS 2 0 0 ACEITAR tudo - lo * 0.0.0.0/0 0.0.0.0/0 3 2 120 FORWARD_direct all - * * 0.0.0.0/0 0.0.0.0/0 4 2 120 FORWARD_IN_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0 5 2 120 FORWARD_IN_ZONES todos - * * 0.0.0.0/0 0.0.0.0/0 6 2 120 FORWARD_OUT_ZONES_SOURCE all - * * 0.0.0.0/0 0.0.0.0/0 7 2 120 FORWARD_OUT_ZONES all - * * 0.0.0.0/0 0.0.0.0/0 8 0 0 DROP all - * * 0.0.0.0/0 0.0.0.0/0 ctstate INVALID ..........
iptables-savesaída da máquina local?-A FORWARD -j REJECT --reject-with icmp-host-prohibited. os pacotes que chegarem à sua máquina e com o endereço de destino fora da sua máquina serão direcionados para a cadeia FORWARD, portanto, abandone esta regra.