OpenVPN -- serveur sur OpenBSD -- client Debian

OpenVPN -- serveur sur OpenBSD -- client Debian - réseaux et sécurité - Linux et OS Alternatifs

Marsh Posté le 31-07-2009 à 04:46:29    

Bonjour a tous,
 
J'ai 2 machines sur un reseau local
 
OpenBSD45 (192.168.1.108), utilisant la gateway 192.168.1.1
Debian501 (192.168.1.105)
 
J'ai install un OpenVPN 2.1rc15 sur OpenBSD, avec pour but que ma Debian s'y connecte et accede a internet via lui.
 
Cote serveur:
 


# cat /etc/openvpn/openvpn.conf
port 443
proto udp
dev tun0
ca /etc/openvpn/ca.crt
cert /etc/openvpn/openvpn-server.crt
key /etc/openvpn/openvpn-server.key
dh /etc/openvpn/dh1024.pem
server 10.8.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
;push "redirect-gateway local def1 bypass-dhcp"
push "redirect-gateway local bypass-dhcp"
push "dhcp-option DNS 24.29.103.15"
push "dhcp-option DNS 24.29.103.16"
keepalive 10 120
comp-lzo
max-clients 3
user _openvpn
group _openvpn
chroot /var/empty
persist-key
persist-tun
status openvpn-status.log
;log         openvpn.log
;log-append  openvpn.log
verb 3
mute 10


 


# cat /etc/pf.conf
scrub in all
nat pass log on em0 from tun0:network to any -> (em0)
#nat pass log on em0 from em0:network to any -> (em0)
pass in
pass out


 
Cote client:
 


debian501-amd64:~# cat /etc/openvpn/client.conf
client
dev tun0
proto udp
remote 192.168.1.108 443
resolv-retry infinite
nobind
;user nobody
;group nogroup
persist-key
persist-tun
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
key /etc/openvpn/client.key
ns-cert-type server
comp-lzo
verb 3
;mute 20
;redirect-gateway


 
 
La connexion s'etablit correctement, je peux pinger le serveur depuis le client par le tunnel, en revanche impossible de pinger l'exterieur.
 


debian501-amd64:~# ping 10.8.0.1
PING 10.8.0.1 (10.8.0.1) 56(84) bytes of data.
64 bytes from 10.8.0.1: icmp_seq=1 ttl=255 time=1.00 ms
64 bytes from 10.8.0.1: icmp_seq=2 ttl=255 time=0.884 ms
^C
--- 10.8.0.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1003ms
rtt min/avg/max/mdev = 0.884/0.946/1.008/0.062 ms
debian501-amd64:~# ping 204.152.191.37
PING 204.152.191.37 (204.152.191.37) 56(84) bytes of data.
^C
--- 204.152.191.37 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1000ms
 
debian501-amd64:~#


 
Depuis le serveur:
 


# tcpdump -n -i em0 | grep "204.152"
tcpdump: listening on em0, link-type EN10MB
10:34:47.504270 10.8.0.6 > 204.152.191.37: icmp: echo request (DF)
10:34:48.504298 10.8.0.6 > 204.152.191.37: icmp: echo request (DF)


 
Donc je me dis que le NAT ne passe pas, ce que me confirme le vide affiche par:
 


# tcpdump -n -e -ttt -i pflog0


 
Pour tester, j'ai essayer de me passer du tunnel, et de NATter le trajet de Debian vers l'exterieur par OpenBSD. Et la ca passe.
 
 
 
Voila, je suis perplexe, si quelqu'un peut m'aider ca serait super.
 
 
Precision (utile?): OpenBSD comme Debian sont des VMware guests (network en mode bridge) sur un Windows XP X64 (lui meme en 192.168.1.102).
 
 
Merci d'avance!
 
S

Reply

Marsh Posté le 31-07-2009 à 04:46:29   

Reply

Marsh Posté le 31-07-2009 à 05:59:46    

sysctl net.inet.ip.forwarding
 
ça donne quoi ?


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 31-07-2009 à 14:24:33    

1
 
si c'etait a 0 les paquets icmp se retrouveraient meme pas a partir sur em0 comme l'indique mon tcpdump, non?

Reply

Marsh Posté le 31-07-2009 à 19:03:44    

je me souviens qu'iptables a des tables PREROUTING et POSTROUTING  
 
y a t'il un equivalent avec packet filter (j'en ai pas trouve)?
 
si j'ai bien compris pf fait son NAT avant le routing, alors que sous iptables on fait la MASQUERADE apres le routing
 
?

Reply

Marsh Posté le 01-08-2009 à 05:02:00    

ouais donc personne ne fait de tunnel nat sous openbsd :D

Reply

Marsh Posté le 01-08-2009 à 19:15:40    

:(

Reply

Marsh Posté le 03-08-2009 à 16:10:10    

Bon,  
 
Le contexte est vraiment different - vos machines virtuelles tout ça - mais je complète au cas où :  
 
Donc si le resolv.conf de votre debian n'est pas modifié pour utiliser celui du serveur openvpn il se peut que la solution soit là.
 
Vous aurez bien sûr prit soin de verifier que les interfaces TAP/TUN ne sont pas bloquées par un iptable également.
 
http://openvpn.net/index.php/open- [...] loads.html
 
Dans le repertoire openvpn-2.1_rc19/contrib/pull-resolv-conf du lien ci-dessus il y a deux petits scripts :  
client.down  client.up  
 
ils faut y faire appel dans votre fichier de config sur la debian :(les explications sont dans les # de ces deux fichiers)  
 
up /etc/openvpn/client.up
down /etc/openvpn/client.down
 
Voilà chez moi sans ces deux scripts, le resolv.conf ne se modifie jamais et impossible bien evidemment de pinger l'exterieur - de surfer etc...sur Etch 32 bits, comme sur Lenny Amd64.
 
Mais je n'utilise pas de BSD et je ne suis pas dans une machine virtuelle.
 
C'est un bug de debian et autres distros debian like parait-il.
 
 
 

Reply

Marsh Posté le 03-08-2009 à 16:40:55    

Je tente du ping en utilisant une addresse et pas un nom, donc le probleme n'est pas dans la resolution. Merci toutefois pour la precision.

Reply

Marsh Posté le 04-08-2009 à 05:56:49    

resolu
 
en mettant 10.8.0.0/24 au lieu de tun0:network, parce que comme l'interface a un /30 par defaut j'allais nulle part
 
 
:jap:

Reply

Marsh Posté le 04-08-2009 à 06:18:36    

y a qqn qui me dire si mon UDP 443 est accessible sur 74.66.250.239?
 
les portscan online font soit du TCP soit moulinent dans le vide :(

Reply

Marsh Posté le 04-08-2009 à 06:18:36   

Reply

Marsh Posté le 04-08-2009 à 08:54:25    


nico@celeborn ~> sudo nmap -p443 -sU 74.66.250.239
 
Starting Nmap 4.76 ( http://nmap.org ) at 2009-08-04 08:59 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 3.20 seconds
 


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 04-08-2009 à 09:22:51    

black_lord a écrit :


nico@celeborn ~> sudo nmap -p443 -sU 74.66.250.239

 

Starting Nmap 4.76 ( http://nmap.org ) at 2009-08-04 08:59 CEST
Note: Host seems down. If it is really up, but blocking our ping probes, try -PN
Nmap done: 1 IP address (0 hosts up) scanned in 3.20 seconds

 



La conclusion de ton scan n'est pas pertinente, tu as oublié le -P0.
La réponse que tu obtiens vient du fait qu'il n'a pas eu de réponse au ping initial.

Message cité 1 fois
Message édité par o'gure le 04-08-2009 à 09:24:36

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 04-08-2009 à 09:26:10    

Quoiqu'il en soit, on obtient aucune réponse de la part de la machine en face :


[ augure@bacchus ~ ] > sudo tcpdump -i eth0 host  74.66.250.239&
[1] 4693
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
[ augure@bacchus ~ ] > sudo nmap -P0 -p443 -sU 74.66.250.239
Starting Nmap 4.68 ( http://nmap.org ) at 2009-08-04 09:23 CEST
09:23:53.567778 IP xxxxxxxxxxxx.38055 > cpe-74-66-250-239.nyc.res.rr.com.https: UDP, length 0
09:23:54.568856 IP xxxxxxxxxxxx.38056 > cpe-74-66-250-239.nyc.res.rr.com.https: UDP, length 0
Interesting ports on cpe-74-66-250-239.nyc.res.rr.com (74.66.250.239):
PORT    STATE         SERVICE
443/udp open|filtered https

 

Nmap done: 1 IP address (1 host up) scanned in 2.097 seconds


Message édité par o'gure le 04-08-2009 à 09:28:04

---------------
Relax. Take a deep breath !
Reply

Marsh Posté le 04-08-2009 à 10:37:44    

o'gure a écrit :


La conclusion de ton scan n'est pas pertinente, tu as oublié le -P0.
La réponse que tu obtiens vient du fait qu'il n'a pas eu de réponse au ping initial.


 
manque de café :o


---------------
uptime is for lousy system administrators what Viagra is for impotent people - mes unixeries - github me
Reply

Marsh Posté le 04-08-2009 à 14:37:25    

argh routeur linksys de m....

Reply

Marsh Posté le 04-08-2009 à 15:57:51    

hier soir je parle avec une fille du live chat support linksys
 
elle me dit que le routeur supporte le port fw que vers les IP fixes
 
c'est qui qu'a code ca :o
 
et le pire c'est que meme apres avoir passe mon serveur vpn en ip fixe, ca marche pas :mad:

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed