Teste stunnel - tcpdump?

Question

Eu tenho a seguinte configuração de stunnel no servidor:

chroot = /var/run/stunnel
setuid = nobody
setgid = nobody

pid = /stunnel.pid

cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.pem
client = no

[https]
accept = 443
connect = 10051

O cliente:

chroot = /var/run/stunnel
setuid = nobody
setgid = nobody

pid = /stunnel.pid

cert = /etc/stunnel/stunnel.pem
key = /etc/stunnel/stunnel.pem
client = yes

[https]
accept = 127.0.0.1:10051
connect = 10.0.10.116:443

Quando executo o 'sudo stunnel' em cada máquina, não recebo erros. Executando os seguintes comandos no cliente para testar o túnel, não recebo nada?

tcpdump port 10051 -n -vvvv

seguido por:

echo "blah" > nc localhost 10051

Estou usando indevidamente o 'tcpdump'? Existe outra maneira de testar isso? Estou usando o Centos 7. O endereço IP do servidor é 10.0.10.116 e o endereço IP do cliente é 10.0.10.27, este é um laboratório de teste com certificados auto-assinados.

Devo acrescentar que se eu emitir o comando tcpdump acima com um sudo:

sudo tcpdump port 10051 -n -vvvv

Eu recebo o seguinte e depois nada:

tcpdump: NFLOG link-layer type filtering not implemented

Não sabe o que isso está me dizendo?

    

Answer 1

Ok, eu consegui para trabalhar com algumas tweeks. Em vez de usar o tcpdump, decidi experimentar o ssh. Então eu mudei a conexão no servidor para:

...
[https]
accept =  443
connect = 22
...

eu digitei

ssh localhost -p 10051

e voltamos

chuck@scorch:~$ ssh chuck@localhost -p 10051
The authenticity of host '[localhost]:10051 ([127.0.0.1]:10051)' can't be 
established.
ECDSA key fingerprint is SHA256:DcEUrtP7I5KJqaZIfsTK+2lNB8AF00Je97z9obNneac.
Are you sure you want to continue connecting (yes/no)? y
Please type 'yes' or 'no': yes
Warning: Permanently added '[localhost]:10051' (ECDSA) to the list of known 
hosts.
chuck@localhost's password:
Welcome to Ubuntu 17.04 (GNU/Linux 4.10.0-19-generic x86_64)
 * Documentation:  https://help.ubuntu.com
 * Management:     https://landscape.canonical.com
 * Support:        https://ubuntu.com/advantage
 * What are your preferred Linux desktop apps?  Help us set the default
desktop apps in Ubuntu 18.04 LTS:
- https://ubu.one/apps1804

11 packages can be updated.
8 updates are security updates.


Last login: Tue Oct  3 15:36:24 2017 from 10.0.10.60
chuck@ion:~$

Observe que o login agora diz 'ion', estou no servidor via ssh portado vis https. O log mostra

2017.10.03 15:38:00 LOG7[0]: Service [https] started
2017.10.03 15:38:00 LOG7[0]: Option TCP_NODELAY set on local socket
2017.10.03 15:38:00 LOG5[0]: Service [https] accepted connection from   
10.0.10.27:36976
2017.10.03 15:38:00 LOG6[0]: Peer certificate not required
2017.10.03 15:38:00 LOG7[0]: TLS state (accept): before/accept 
initialization
2017.10.03 15:38:00 LOG7[0]: Get session callback
2017.10.03 15:38:00 LOG7[0]: SNI: no virtual services defined
2017.10.03 15:38:00 LOG7[0]: New session callback
2017.10.03 15:38:00 LOG7[0]:      1 server accept(s) requested
2017.10.03 15:38:00 LOG7[0]:      1 server accept(s) succeeded
2017.10.03 15:38:00 LOG7[0]:      0 server renegotiation(s) requested
2017.10.03 15:38:00 LOG7[0]:      0 session reuse(s)
2017.10.03 15:38:00 LOG7[0]:      0 internal session cache item(s)
2017.10.03 15:38:00 LOG7[0]:      0 internal session cache fill-up(s)
2017.10.03 15:38:00 LOG7[0]:      1 internal session cache miss(es)
2017.10.03 15:38:00 LOG7[0]:      0 external session cache hit(s)
2017.10.03 15:38:00 LOG7[0]:      0 expired session(s) retrieved
2017.10.03 15:38:00 LOG6[0]: TLS accepted: new session negotiated
2017.10.03 15:38:00 LOG6[0]: No peer certificate received
2017.10.03 15:38:00 LOG6[0]: Negotiated TLSv1.2 ciphersuite ECDHE-RSA-
AES256-GCM-SHA384 (256-bit encryption)
2017.10.03 15:38:00 LOG7[0]: Compression: null, expansion: null
2017.10.03 15:38:00 LOG6[0]: failover: round-robin, starting at entry #1
2017.10.03 15:38:00 LOG6[0]: s_connect: connecting 127.0.0.1:22
2017.10.03 15:38:00 LOG7[0]: s_connect: s_poll_wait 127.0.0.1:22: waiting 10 
seconds
2017.10.03 15:38:00 LOG5[0]: s_connect: connected 127.0.0.1:22
2017.10.03 15:38:00 LOG6[0]: persistence: 127.0.0.1:22 cached
2017.10.03 15:38:00 LOG5[0]: Service [https] connected remote server from 
127.0.0.1:54818
2017.10.03 15:38:00 LOG7[0]: Option TCP_NODELAY set on remote socket
2017.10.03 15:38:00 LOG7[0]: Remote descriptor (FD=9) initialized

Então eu sei que funciona no Ubuntu. Eu notei que durante a instalação do stunnel ele criou automaticamente um usuário, grupo e serviço 'stunnel4'. Então eu acho que preciso tentar isso em Centos e ver o que acontece.

Eu finalmente consegui que funcionasse no Centos. Acontece que eu pensei que tinha desligado o firewall, mas eu não tinha. Adicionar as portas apropriadas ao firewall resolveu o problema. No entanto, ainda não consigo fazer funcionar o tcpdump ...