1 votes

Tunnelage dans un vpn avec squid et ssh-tunnel

Intro :

Afin d'accéder à la console d'administration d'un certain centre de données, je suis censé utiliser un VPN. Cependant, en raison de la configuration du réseau de l'entreprise, je ne peux pas établir de connexion VPN (on m'a dit qu'ils ne créeraient pas le tunnel nécessaire pour moi). En même temps, on m'a permis de trouver un contournement). Pour le contourner, j'utilise le navigateur google chrome avec un proxy réglé sur localhost:9999. Il y a un tunnel ssh qui connecte localhost:9999 avec une instance de squid sur un serveur dédié. Le serveur dédié a établi une connexion VPN en utilisant le vpnc.

Lorsque je teste la navigation web, je n'ai aucun problème à me connecter à mon compte Gmail via ce proxy. Donc http et https sont redirigés correctement.

Lorsque j'essaie d'accéder à l'adresse https:///login.html, Chrome me signale une erreur 7 (net::ERR_TIMED_OUT) : L'opération a été interrompue

ifconfig tun0 (tun0 étant la connexion vpn)

tun0      Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  
          inet addr:192.168.237.1  P-t-P:192.168.237.1  Mask:255.255.255.255

extrait de squid access.log :

1322248499.456  29972 94.23.35.103 TCP_MISS/000 0 CONNECT 172.30.3.93:443 - NONE/- -
1322248499.484  30000 94.23.35.103 TCP_MISS/000 0 CONNECT 172.30.3.93:443 - NONE/- -
1322248529.478  29905 94.23.35.103 TCP_MISS/000 0 CONNECT 172.30.3.93:443 - NONE/- -

commande ip r

180.150.133.253 via 94.23.35.254 dev eth0  src 94.23.35.103 
192.168.237.0/24 dev tun0  scope link 
192.168.122.0/24 dev virbr0  proto kernel  scope link  src 192.168.122.1 
94.23.35.0/24 dev eth0  proto kernel  scope link  src 94.23.35.103 
172.30.0.0/22 dev tun0  scope link 
default via 94.23.35.254 dev eth0  metric 100

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 65535 bytes
20:39:41.146346 IP 192.168.237.1.33810 > 172.30.3.93.https: Flags [S], seq 2990531692, win 13720, options [mss 1372,sackOK,TS val 34961006 ecr 0,nop,wscale 7], length 0
20:39:41.206331 IP 192.168.237.1.50869 > 172.30.3.93.https: Flags [S], seq 1974326041, win 13720, options [mss 1372,sackOK,TS val 34961012 ecr 0,nop,wscale 7], length 0
20:39:41.370436 IP 172.30.3.93.https > 192.168.237.1.33810: Flags [S.], seq 953273047, ack 2990531693, win 5792, options [mss 1380,sackOK,TS val 4294958113 ecr 34961006,nop,wscale 2], length 0
20:39:41.370458 IP 192.168.237.1 > 172.30.3.93: ICMP 192.168.237.1 tcp port 33810 unreachable, length 68
20:39:41.427724 IP 172.30.3.93.https > 192.168.237.1.50869: Flags [S.], seq 3867774677, ack 1974326042, win 5792, options [mss 1380,sackOK,TS val 4294958118 ecr 34961012,nop,wscale 2], length 0
20:39:41.427743 IP 192.168.237.1 > 172.30.3.93: ICMP 192.168.237.1 tcp port 50869 unreachable, length 68
20:39:44.147985 IP 192.168.237.1.33810 > 172.30.3.93.https: Flags [S], seq 2990531692, win 13720, options [mss 1372,sackOK,TS val 34961307 ecr 0,nop,wscale 7], length 0
20:39:44.207981 IP 192.168.237.1.50869 > 172.30.3.93.https: Flags [S], seq 1974326041, win 13720, options [mss 1372,sackOK,TS val 34961313 ecr 0,nop,wscale 7], length 0
20:39:50.157964 IP 192.168.237.1.33810 > 172.30.3.93.https: Flags [S], seq 2990531692, win 13720, options [mss 1372,sackOK,TS val 34961908 ecr 0,nop,wscale 7], length 0
20:39:50.217978 IP 192.168.237.1.50869 > 172.30.3.93.https: Flags [S], seq 1974326041, win 13720, options [mss 1372,sackOK,TS val 34961914 ecr 0,nop,wscale 7], length 0
20:40:02.197916 IP 192.168.237.1.33810 > 172.30.3.93.https: Flags [S], seq 2990531692, win 13720, options [mss 1372,sackOK,TS val 34963112 ecr 0,nop,wscale 7], length 0
20:40:02.237994 IP 192.168.237.1.50869 > 172.30.3.93.https: Flags [S], seq 1974326041, win 13720, options [mss 1372,sackOK,TS val 34963116 ecr 0,nop,wscale 7], length 0
20:40:11.245849 IP 192.168.237.1.43253 > 172.30.3.93.https: Flags [S], seq 885758311, win 13720, options [mss 1372,sackOK,TS val 34964016 ecr 0,nop,wscale 7], length 0
20:40:11.467567 IP 172.30.3.93.https > 192.168.237.1.43253: Flags [S.], seq 1102840217, ack 885758312, win 5792, options [mss 1380,sackOK,TS val 4294961122 ecr 34964016,nop,wscale 2], length 0
20:40:11.467591 IP 192.168.237.1 > 172.30.3.93: ICMP 192.168.237.1 tcp port 43253 unreachable, length 68
20:40:14.247958 IP 192.168.237.1.43253 > 172.30.3.93.https: Flags [S], seq 885758311, win 13720, options [mss 1372,sackOK,TS val 34964317 ecr 0,nop,wscale 7], length 0

et je peux ping la machine ok.

PING 172.30.3.93 (172.30.3.93) 56(84) bytes of data.
64 bytes from 172.30.3.93: icmp_req=1 ttl=64 time=221 ms
64 bytes from 172.30.3.93: icmp_req=2 ttl=64 time=222 ms
64 bytes from 172.30.3.93: icmp_req=3 ttl=64 time=221 ms
64 bytes from 172.30.3.93: icmp_req=4 ttl=64 time=226 ms
64 bytes from 172.30.3.93: icmp_req=5 ttl=64 time=221 ms
64 bytes from 172.30.3.93: icmp_req=6 ttl=64 time=221 ms
^C
--- 172.30.3.93 ping statistics ---
7 packets transmitted, 6 received, 14% packet loss, time 6001ms
rtt min/avg/max/mdev = 221.068/222.406/226.608/1.991 ms

Quelqu'un peut-il me donner des indications sur : -Quelle est l'erreur évidente ici (j'espère qu'il y en a une ;)) ? -Quels sont les logs à consulter pour déboguer le problème ?

0 votes

Vérifier les règles du pare-feu ( iptables -L -vn ) - les paquets ICMP port unreachable vus dans votre tcpdump pourraient être générés par un REJECT dans une règle iptables.

0voto

TheLegend0713 Points 21
20:40:11.245849 IP 192.168.237.1.43253 > 172.30.3.93.https: Flags [S], seq 885758311, win 13720, options [mss 1372,sackOK,TS val 34964016 ecr 0,nop,wscale 7], length 0
20:40:11.467567 IP 172.30.3.93.https > 192.168.237.1.43253: Flags [S.], seq 1102840217, ack 885758312, win 5792, options [mss 1380,sackOK,TS val 4294961122 ecr 34964016,nop,wscale 2], length 0
20:40:11.467591 IP 192.168.237.1 > 172.30.3.93: ICMP 192.168.237.1 tcp port 43253 unreachable, length 68

La première ligne indique que votre machine a envoyé le drapeau SYN, c'est-à-dire [S], pour initier le handshake avec le serveur (numéro de séquence du segment 885758311).

La deuxième ligne indique que le serveur a acquitté avec le drapeau [S.] la demande SYN de votre machine (ack 885758312 c'est-à-dire 885758311+1).

Je ne suis pas sûr de la troisième ligne mais je pense qu'elle indique que l'hôte de destination (votre machine) informe l'hôte d'envoi (machine distante) que le port demandé, à savoir 43253, n'est pas accessible. Il doit donc y avoir quelque chose dans votre pare-feu qui rejette cette connexion. Vérifiez les règles du pare-feu.

0 votes

Bonjour, et merci pour les conseils - le pare-feu restrictif était le problème. J'ai dû ajouter : {{ iptables -A INPUT -j ACCEPT -s VPN_GW_IP -p esp iptables -A INPUT -j ACCEPT -s VPN_GW_IP -p udp -m multiport --sport isakmp, 10000 iptables -A INPUT -j ACCEPT -i tun0 iptables -A OUTPUT -j ACCEPT -d VPN_GW_IP -p esp iptables -A OUTPUT -j ACCEPT -d VPN_GW_IP -p udp -m multiport --dport isakmp, 10000 iptables -A OUTPUT -j ACCEPT -o tun0 }} dans le pare-feu script, où VPN_GW_IP est l'ip du point de terminaison vpn qui m'a été donné.

0 votes

@user102150, merci d'avoir posté la solution. Pouvez-vous éditer votre commentaire avec un formatage correct ? Car il est difficilement lisible.

0 votes

Je suis vraiment désolé, mais je n'arrive pas à utiliser le bloc de code, il ne veut pas fonctionner pour moi. En ce qui concerne la lecture du désordre - chaque ligne commence par le mot "iptables", il est facile de le copier et de l'analyser manuellement avec de nouvelles lignes.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X