VPN SSH - não é possível enviar pacotes ICMP para confirmar se a VPN está ativa

Question

VPN SSH - não é possível enviar pacotes ICMP para confirmar se a VPN está ativa

#1 resposta do (1 votos)

2

Estou tentando configurar uma VPN baseada em SSH entre dois dispositivos, seguindo as instruções do site aqui em um ambiente de laboratório .

Os 2 dispositivos são o Kali Linux 2017.1 (cliente) e o Ubuntu Linux Mint 18.2 (servidor). Os endereços IP dos dispositivos são:

Kali Linux (cliente) - 192.168.56.103, IP do ponto de extremidade da VPN: 1.1.1.2
Linux Mint (servidor) - 192.168.56.102, IP do ponto de extremidade da VPN: 1.1.1.1.

Eu executei as etapas a seguir em cada dispositivo.

No cliente,

sudo ssh -w 0:0 [email protected]
ip link set tun0 up
ip addr add 1.1.1.2/32 peer 1.1.1.1 dev tun0

No servidor,

service ssh start
ip link set tun0 up
ip addr add 1.1.1.1/32 peer 1.1.1.2 dev tun0

A saída do cliente é mostrada abaixo:

$ ifconfig tun0
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500             
    inet 1.1.1.2  netmask 255.255.255.255  destination 1.1.1.1             
    inet6 fe80::73bc:5f32:6ba2:9419  prefixlen 64  scopeid 0x20<link>      
    unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)                                                                      
    RX packets 597  bytes 50040 (48.8 KiB)                                 
    RX errors 0  dropped 0  overruns 0  frame 0                            
    TX packets 602  bytes 50280 (49.1 KiB)                                 
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

A saída do servidor é mostrada abaixo:

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
      inet addr:1.1.1.1  P-t-P:1.1.1.2  Mask:255.255.255.255
      inet6 addr: fe80::d0f:d97a:3bc0:c1ad/64 Scope:Link
      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:671 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:500 
      RX bytes:0 (0.0 B)  TX bytes:56256 (56.2 KB)

Enquanto os IPs do túnel estão configurados, não consigo comunicar pimp icmp entre os 2 IPs - 1.1.1.1, 1.1.1.2

Se eu iniciar o ping do servidor para o cliente, posso ver que o cliente está recebendo os pings do servidor e respondendo, mas o servidor não está recebendo as respostas.

Então, no servidor, eu iniciei os pings e monitorei a resposta do tcpdump.

$ ping 1.1.1.2
$ sudo tcpdump -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
03:07:01.494334 IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 8371, seq 810, length 64
03:07:02.517661 IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 8371, seq 811, length 64
03:07:03.541852 IP 1.1.1.1 > 1.1.1.2: ICMP echo request, id 8371, seq 812, length 64

No cliente, vejo as seguintes respostas sendo enviadas pelo cliente no tcpdump, mas elas não são registradas pelo servidor

$ tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
03:09:48.485679 IP 1.1.1.1 > kali: ICMP echo request, id 8371, seq 1125, length 64
03:09:48.485711 IP kali > 1.1.1.1: ICMP echo reply, id 8371, seq 1125, length 64
03:09:49.510028 IP 1.1.1.1 > kali: ICMP echo request, id 8371, seq 1126, length 64
03:09:49.510052 IP kali > 1.1.1.1: ICMP echo reply, id 8371, seq 1126, length 64

Alguém consegue identificar porque não consigo me comunicar entre o cliente e o servidor? Não consigo enviar com êxito nenhum protocolo de rede (não apenas icmp) entre o cliente e o servidor.

Já tentei o seguinte:

No lado do servidor, verifiquei se o PermitTunnel está ativado e o usuário root é usado de acordo com os requisitos declarados na documentação.
Eu removi todas as regras de firewall do iptables e verifiquei se a política padrão é ACCEPT.
```
iptables -t nat -F
iptables -t filter -F
iptables -t mangle -F
```

Eu desativei e removi o ufw para teste por:

sudo ufw disable 
sudo apt-get remove ufw

Tentei procurar outras instruções aqui e aqui , mas eles não me deram nenhuma pista sobre qual poderia ser o problema.

Aqui está o meu arquivo sshd_config do servidor.

# Package generated configuration file
# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 3600
ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
#PermitRootLogin prohibit-password
PermitRootLogin yes
PermitTunnel yes
StrictModes yes
GatewayPorts yes
AllowTcpForwarding yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

X11Forwarding yes
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

ATUALIZAÇÃO: De acordo com o feedback do dirkt, agora usei endereços IP internos. 10.1.1.1 em vez de 1.1.1.1, 10.1.1.2 em vez de 1.1.1.2. No entanto, o problema ainda persiste.

No cliente,

tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
    inet 10.1.1.1  netmask 255.255.255.255  destination 10.1.1.2
    inet6 fe80::23ca:f7ce:e4c7:24c8  prefixlen 64  scopeid 0x20<link>
    unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
    RX packets 316  bytes 26436 (25.8 KiB)
    RX errors 0  dropped 0  overruns 0  frame 0
    TX packets 320  bytes 26628 (26.0 KiB)
    TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

No servidor,

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
      inet addr:10.1.1.2  P-t-P:10.1.1.1  Mask:255.255.255.255
      inet6 addr: fe80::e633:5f17:9b14:ae06/64 Scope:Link
      UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
      RX packets:0 errors:0 dropped:0 overruns:0 frame:0
      TX packets:191 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:500 
      RX bytes:0 (0.0 B)  TX bytes:15936 (15.9 KB)

Além disso, aqui está a tabela de roteamento dos comandos ip route:

No cliente,

default via 10.0.2.2 dev eth0 
10.0.2.0/24 dev eth0 proto kernel scope link src 10.0.2.15 
10.1.1.2 dev tun0 proto kernel scope link src 10.1.1.1 
192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.103 
192.168.56.0/24 dev eth1 proto kernel scope link src 192.168.56.103 metric 100

No servidor,

default via 10.0.2.2 dev enp0s3  proto static  metric 100 
10.0.2.0/24 dev enp0s3  proto kernel  scope link  src 10.0.2.15  metric 100 
10.1.1.1 dev tun0  proto kernel  scope link  src 10.1.1.2 
169.254.0.0/16 dev enp0s3  scope link  metric 1000 
172.17.0.0/16 dev docker0  proto kernel  scope link  src 172.17.0.1 linkdown 
172.18.0.0/16 dev br-56e99b53b1be  proto kernel  scope link  src 172.18.0.1 linkdown 
192.168.56.0/24 dev enp0s8  proto kernel  scope link  src 192.168.56.102  metric 100

UPDATE Ao executar o telnet, fica claro que o tráfego está sendo encaminhado do Kali Linux (cliente) para o Linux Mint (servidor), mas não o contrário. Mesmo depois que a porta 12345 é aberta no cliente, os pacotes SynAck não estão sendo registrados pelo cliente.

No servidor, nós executamos o seguinte:

telnet 10.1.1.1 12345
Trying 10.1.1.1....

No servidor, vemos pacotes syn para o cliente

tcpdump -ni tun0
root@linuxmint-VirtualBox /home/linuxmint # tcpdump -ni tun0 
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
17:47:28.869970 IP 10.1.1.2.49674 > 10.1.1.1.12345: Flags [S], seq 2551141293, win 29200, options [mss 1460,sackOK,TS val 2598500 ecr 0,nop,wscale 7], length 0
17:47:29.874205 IP 10.1.1.2.49674 > 10.1.1.1.12345: Flags [S], seq 2551141293, win 29200, options [mss 1460,sackOK,TS val 2598752 ecr 0,nop,wscale 7], length 0
17:47:31.890376 IP 10.1.1.2.49674 > 10.1.1.1.12345: Flags [S], seq 2551141293, win 29200, options [mss 1460,sackOK,TS val 2599256 ecr 0,nop,wscale 7], length 0

No cliente, vemos as respostas de redefinição voltando, mas o telnet apenas fica lá.

tcpdump -ni tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode     
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes           
17:47:18.918860 IP 10.1.1.2.49676 > 10.1.1.1.12345: Flags [S], seq 3064866770, win 29200, options [mss 1460,sackOK,TS val 2605333 ecr 0,nop,wscale 7], length 0                                      
17:47:18.918899 IP 10.1.1.1.12345 > 10.1.1.2.49676: Flags [R.], seq 0, ack 3064866771, win 0, length 0                                                        
17:47:19.921367 IP 10.1.1.2.49676 > 10.1.1.1.12345: Flags [S], seq 3064866770, win 29200, options [mss 1460,sackOK,TS val 2605584 ecr 0,nop,wscale 7], length 0                                      
17:47:19.921412 IP 10.1.1.1.12345 > 10.1.1.2.49676: Flags [R.], seq 0, ack 1, win 0, length 0

ssh networking vpn ping linux

por John 21.08.2017 / 19:20

1 resposta

Tags ssh networking vpn ping linux

O script Autohotkey não funciona como pretendido por que existem módulos carregados que não estão sendo usados?

score 1 · Answer 1

A máscara de rede que você selecionou (255.255.255.255) não deixa espaço para os hosts. Tecnicamente, você tem o endereço de rede e o endereço de broadcast no mesmo endereço (10.1.1.1). minha recomendação é, para mudar a máscara de rede para 255.255.255.252 se você quiser adicionar mais hosts (como esta máscara de rede deixa apenas espaço para dois hosts), então eu recomendo que você mude para uma aparência de subnetmask inferior no google para calculadoras de sub-rede para mais exemplos .