Como criar / configurar vpn usando apenas SSH?

9

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
..........
Todos
fonte

Respostas:

4

O endereço de origem dos pacotes deve ser substituído por um dos endereços da máquina local, para que as respostas possam ser recebidas pela máquina local; caso contrário, não há motivo (bom) para enviar esses pacotes para os próximos roteadores; a resposta não pode ser capturada de qualquer maneira. iptables MASQUERADEe SNATsão úteis para alterar o endereço de origem desses pacotes:

[user@local ~]$ iptables -t nat -A POSTROUTING -s 10.0.2.2/32 ! -d 10.0.2.1/30 -j MASQUERADE -o eth0
xin
fonte
Obrigado pela resposta @xin. Executei o comando que você forneceu, mas ainda recebi a mesma resposta. Eu executei o tcpdump em eth0 e tun0. pacotes não são roteados para eth0. tun0 ainda está tentando acessar o google. Preciso, de alguma forma, rotear pacotes de tun0 para eth0?
Ali
1
Se a máquina local usar a interface eth0 para conectar-se à Internet, os pacotes deverão ir para eth0 mesmo sem esse comando. Então, talvez alguma configuração de firewall esteja envolvida. Você pode colocar a iptables-savesaída da máquina local?
xin
Eu adicionei a saída do iptables-save à postagem original.
Ali
O firewalld precisava ser desligado. Executei seu comando depois de desligar o firewalld, e a conexão começou a funcionar! Agradeço sua ajuda! Notas do Google Checkout na postagem original para ver o progresso.
Ali
1
bom trabalho. Parece que o problema é regra iptable -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.
xin