OpenVPN -- serveur sur OpenBSD -- client Debian - réseaux et sécurité - Linux et OS Alternatifs
Marsh Posté le 31-07-2009 à 05:59:46
sysctl net.inet.ip.forwarding
ça donne quoi ?
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?
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
?
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.
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.
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
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
Marsh Posté le 04-08-2009 à 08:54:25
|
Marsh Posté le 04-08-2009 à 09:22:51
black_lord 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.
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 :
Nmap done: 1 IP address (1 host up) scanned in 2.097 seconds |
Marsh Posté le 04-08-2009 à 10:37:44
o'gure a écrit : |
manque de café
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
et le pire c'est que meme apres avoir passe mon serveur vpn en ip fixe, ca marche pas
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