# VPN + Proxy + curl = erreur **URL:** \ **Category:** Support Debian\ **Tags:** proxy, curl, vpn\ **Created:** [Janvier 20, 2021, 8:53 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775 "2021-01-20T20:53:49Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![LePsy666](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/6bbea6/32.png) [@LePsy666](https://www.debian-fr.org/u/LePsy666)\ **Post date:** [Janvier 20, 2021, 8:53 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/1 "2021-01-20T20:53:49Z")
Bonjour et bonne année ! J’ai un souci avec la connexion a des sites qui disparaît lorsque je me déconnecte de mon VPN. Le souci doit venir de la mais j’ai eu beau chercher, je n’ai pas trouvé comment fixer. Voici ma config : J’ai un serveur dédié sur lequel j’ai installé et configuré `pptpd`. Mes clients se connectent via `pptp-linux`. Je peux sans problème pinguer et me connecter du serveur aux clients et inversement. Les clients utilisent le serveur comme proxy ( « `/sbin/route add default dev ppp0` » sur les clients et « `iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE` » sur le serveur ). Je pense que c’est la que se situe le problème du coup. Une fois cette configuration faite, lorsque je tente un curl, les sites web ne sont pas joignables. J’ai une erreur sur le https ```nohighlight curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.google.fr:443 ``` et en http ```nohighlight curl: (56) Recv failure: Connection reset by peer ``` Si vous avez une idée de l’endroit ou chercher, je suis preneur, j’ai tenté d’utiliser `tcpdump` mais je ne maîtrise pas les commandes. Je suis donc ouvert à toutes suggestions ! Merci d’avance. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Janvier 20, 2021, 8:56 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/2 "2021-01-20T20:56:17Z")
> [@LePsy666](#): > > curl: (35) OpenSSL SSL\_connect: SSL\_ERROR\_SYSCALL in connection to Il est possible que ce soit lié à l’IPv6. en fait quadn tu fait www.google.fr:443, l’ip de [www.google.fr](http://www.google.fr) est une ipv6. Ta machine doit traiter l’IPv6 en priorité à l’IPv4. ---
**Author:** ![Almtesh](https://www.debian-fr.org/user_avatar/www.debian-fr.org/almtesh/32/10312_2.png) [@Almtesh](https://www.debian-fr.org/u/Almtesh)\ **Post date:** [Janvier 21, 2021, 6:00 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/3 "2021-01-21T06:00:10Z")
Question bête, que donne comme résultat la même commande exécutée sur le serveur VPN ? ---
**Author:** ![LePsy666](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/6bbea6/32.png) [@LePsy666](https://www.debian-fr.org/u/LePsy666)\ **Post date:** [Janvier 21, 2021, 8:54 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/4 "2021-01-21T08:54:11Z")
Ca ne semble pas venir de la, j’ai testé sur un site en ipv4 et j’ai le même souci : ```nohighlight [root@home] [~] $ curl -v https://www.debian-fr.org [...] * Expire in 15 ms for 1 (transfer 0x1b4c8a0) * Expire in 15 ms for 1 (transfer 0x1b4c8a0) * Expire in 50 ms for 1 (transfer 0x1b4c8a0) * Trying 148.251.85.151... * TCP_NODELAY set * Expire in 149969 ms for 3 (transfer 0x1b4c8a0) * Expire in 200 ms for 4 (transfer 0x1b4c8a0) * Connected to www.debian-fr.org (148.251.85.151) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: none CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * Operation timed out after 300191 milliseconds with 0 out of 0 bytes received * Closing connection 0 curl: (28) Operation timed out after 300191 milliseconds with 0 out of 0 bytes received [root@home] [~] $ ``` Ca semble principalement etre sur du https du coup, j’ai testé le meme site en http et j’ai bien eu un resultat ( 301 redirect sur le https du coup ) ---
**Author:** ![LePsy666](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/6bbea6/32.png) [@LePsy666](https://www.debian-fr.org/u/LePsy666)\ **Post date:** [Janvier 21, 2021, 8:56 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/5 "2021-01-21T08:56:43Z")
Depuis le serveur VPN aucun problème, la réponse arrive immédiatement. J’ai vu des posts sur des problèmes similaires parlant de mettre le MTU a jour, je ne suis pas certain de l’avoir bien fait ( pas trop compris ce que c’était supposé faire ) mais j’ai tenté pourtant ca ne semble avoir rien changé. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Janvier 22, 2021, 1:29 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/6 "2021-01-22T13:29:23Z")
> [@LePsy666](#): > > Ca ne semble pas venir de la, j’ai testé sur un site en ipv4 et j’ai le même souci : [debian-fr.org](http://debian-fr.org) a une adresse IPv6, si ton système priorise l’IPv6 c’est ipv6 qui sera utilisé même s’il y a une ipv4: ``` >nslookup debian-fr.org Serveur : ******* Address: ******** Réponse ne faisant pas autorité : Nom : debian-fr.org Addresses: 2a01:4f8:202:6091::100 148.251.85.151 ``` ---
**Author:** ![LePsy666](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/6bbea6/32.png) [@LePsy666](https://www.debian-fr.org/u/LePsy666)\ **Post date:** [Janvier 22, 2021, 3:19 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/7 "2021-01-22T15:19:05Z")
Ca ne sort pas d’ip v6 depuis mon serveur VPN : ```nohighlight [root@master] [~] $ nslookup debian-fr.org Server: 127.0.0.1 Address: 127.0.0.1#53 Non-authoritative answer: Name: debian-fr.org Address: 148.251.85.151 [root@master] [~] $ ``` mais si le problème vient de l’ipv6, une idée de comment corriger ca ? Je vais voir pour configurer de l’ipv6 sur mon serveur mais le vpn sortant par l’ipv4 je ne pense pas que ca change. A voir si je peux configurer une ipv4 et une ipv6 en sortie, si qqn sait le faire avec l’outil que j’ai utilisé alors je suis preneur 🙂 ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Janvier 22, 2021, 7:22 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/8 "2021-01-22T19:22:11Z")
A priori si tu n’a pas de ipv6 configuré alors c’est en ipv4 donc ne change rien. Le truc ce serait de sniffer les flux, soit avec wireshark, qui est plus facile à utiliser ou avec tcpdump (plus cossus). Est(ce que tu as le même problème en utilisant wget au lieu de curl? ---
**Author:** ![LePsy666](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/6bbea6/32.png) [@LePsy666](https://www.debian-fr.org/u/LePsy666)\ **Post date:** [Janvier 25, 2021, 9:15 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/9 "2021-01-25T09:15:59Z")
J’ai pu cerner un peu plus le problème ce week end. Je ne sais pas pour quelle raison ca bloquait avant ( j’ai quand meme nettoyé ma table de postrouting sur le serveur VPN et depuis des sites publiques qui me posaient problème avant redeviennent accessibles. Par contre les sites auxquels je n’accede pas ( et c’est ce qui me pose problème ) sont ceux que j’héberge sur mon serveur VPN lorsque j’applique la règle de routage suivante : > /sbin/route add default dev ppp0 L’idée étant de sortir par l’ip publique du VPN a la façon d’un proxy. Est-ce qu’elle est mal construite ? Lorsqu’elle est active, je récupère bien une ip publique du serveur ( mais pas forcément la même en fonction du site testé =\> [monip.org](http://monip.org) \<=\> ipaddr.ovh j’ai peut être raté un truc ? Les reverse des deux ips sont correctement configurés, j’utilise une wildcard par contre par défaut sur l’une des deux ) Lorsqu’elle est inactive, plus de problème mis a part que c’est mon IP perso qui apparait et ca me pose problème pour des ACL me donnant accès à d’autres services. Je ne connais pas wireshark et j’ai tenté d’utiliser tcpdump mais ne sachant pas trop quoi chercher, j’ai aussi du mal a l’utiliser. Si vous avez des conseils, je suis preneur. Merci d’avance ! ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Janvier 25, 2021, 3:39 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/10 "2021-01-25T15:39:44Z")
> [@LePsy666](#): > > Par contre les sites auxquels je n’accede pas ( et c’est ce qui me pose problème ) sont ceux que j’héberge sur mon serveur VPN lorsque j’applique la règle de routage suivante : Ton serveur VPN sert aussi d’hébergement web? Quand tu te connectes en VPN tu utilises une IP publique qui est la même que lorsque tu résous l’adresse du serveur web? > [@LePsy666](#): > > Lorsqu’elle est active, Tu parles de la route indiquée? > [@LePsy666](#): > > ( mais pas forcément la même en fonction du site testé =\> [monip.org](http://monip.org) \<=\> ipaddr.ovh j’ai peut être raté un truc ? Les reverse des deux ips sont correctement configurés, j’utilise une wildcard par contre par défaut sur l’une des deux ) je n’y comprends rien du tout… Ton serveur web est sur quelle adresse et elle est résolue avec quelle ip? Où utilises-tu un wildcard? on ne peut pas utiliser un wildcard sur une adresse http. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Janvier 25, 2021, 3:55 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/11 "2021-01-25T15:55:23Z")
> [@LePsy666](#): > > Les clients utilisent le serveur comme proxy ( « `/sbin/route add default dev ppp0` » sur les clients et « `iptables -t nat -A POSTROUTING -o eno1 -j MASQUERADE` » sur le serveur ) Ce n’est pas un proxy, c’est un routeur NAT. Ou alors tu ne nous dis pas tout. > [@Zargos](#): > > quand tu fait [www.google.fr:443](http://www.google.fr:443), l’ip de [www.google.fr](http://www.google.fr) est une ipv6. Pas forcément. Si le client n’a pas de connectivité IPv6 globale, il ne va pas chercher à utiliser l’adresse IPv6 du site. Dans le cas contraire, si le VPN ne modifie pas la route IPv6 par défaut du client, alors il n’y a aucune raison que la connectivité IPv6 soit affectée. > [@LePsy666](#): > > Ca ne sort pas d’ip v6 depuis mon serveur VPN : > > ```auto > [root@master] [~] $ nslookup debian-fr.org > > ``` Forcément, si tu ne demandes pas, ça ne sort pas. nslookup ne fait qu’une requête de type A (adresse IPv4) par défaut. Essaie plutôt ``` nslookup -q=AAAA debian-fr.org ``` > [@LePsy666](#): > > Par contre les sites auxquels je n’accede pas ( et c’est ce qui me pose problème ) sont ceux que j’héberge sur mon serveur VPN lorsque j’applique la règle de routage suivante : > > > /sbin/route add default dev ppp0 Les connexions via le VPN arrivent par une interface et avec une adresse source différentes. Est-ce qu’il y a des règles de filtrage (iptables, nftables) basées sur l’interface d’entrée ou l’adresse IP source sur ton serveur ? ---
**Author:** ![LePsy666](https://www.debian-fr.org/letter_avatar_proxy/v4/letter/l/6bbea6/32.png) [@LePsy666](https://www.debian-fr.org/u/LePsy666)\ **Post date:** [Janvier 25, 2021, 5:25 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/12 "2021-01-25T17:25:23Z")
🙂 ca n’est pas que je ne dis pas tout, c’est plus que je ne sais pas ce qu’il faut que je partage comme info ( et pas envie d’en dire trop, je ne suis pas expert, je ne veux pas risquer d’attaque parce que j’aurai mal configuré quelque chose et que mon serveur soit connu. Je vais tenter de préciser tout ce que je peux. Il s’agit 'un serveur dédié chez un hébergeur. Il dispose de deux adresses « IP\_A » et « IP\_B ». Sur chaque client j’ai utilisé : **pptpsetup --create VPN --server IP\_A --username USER --password XXXXXXXXXXXXX --encrypt** Pour démarrer la connexion VPN, j’utilise **pon VPN** et j’obtiens bien mon ip sur le réseau privé. Je fais ensuite un **route add default dev ppp0** dans le but que tout les paquets sortants passent par l’ip de mon serveur dédié ( IP\_A ou IP\_B ca ne me pose pas de problème tant que ca ne change pas ). Mon problème est que lorsque j’utilise le **route add default dev ppp0** sur mon client, je n’arrive plus a accéder aux sites https qui doivent répondre sur l’IP\_B de mon serveur. Je viens de tenter un curl sur l’IP\_A, cela fonctionne en http et https. Concernant la wildcard, c’est sur mon serveur DNS que j’en ai une pour que \*.mondomaine.tld pointe sur l’IP\_B Pour l’iptables sur le host, j’ai un fail2ban, je viens de tenter de le désactiver mais ca n’a rien changé. Le curl sur mon site depuis mon réseau privé me renvoie toujours un **OpenSSL SSL\_connect: SSL\_ERROR\_SYSCALL in connection to site.mondomaine.tld:443** ( et coté nginx je ne vois aucune connexion ) Du coté de tcpdump je vois bien la connexion « partir » du client mais pas arriver sur le serveur. Chose étrange, meme si l’un et l’autre peuvent se pinguer mutuellement sur leur ip privée, le serveur n’a pas d’interface configurée avec l’ip privée contrairement au client. Je creuserai ca ce soir je pense mais si vous avez d’autres idées, je suis preneur. Merci d’avance ! ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Janvier 25, 2021, 5:33 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/13 "2021-01-25T17:33:25Z")
> [@PascalHambourg](#): > > Forcément, si tu ne demandes pas, ça ne sort pas. nslookup ne fait qu’une requête de type A (adresse IPv4) par défaut. En fait il reçoit la requete ipv4 et ipv6 si ton pc est en ipv6. ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Janvier 25, 2021, 7:42 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/14 "2021-01-25T19:42:24Z")
> [@LePsy666](#): > > Je viens de tenter un curl sur l’IP\_A, cela fonctionne en http et https. Une explication possible est que le client PPTP (pptp-linux ?) crée une route spécifique vers l’adresse IP du serveur VPN, afin que celui-ci reste joignable si la route par défaut est modifiée pour passer par le VPN. A vérifier avec `ip route` sur le client lorsque le VPN est monté. Si c’est le cas, alors les connexions vers IP\_A sont routées hors du VPN. Quant aux règles de filtrage, il suffit d’examiner la sortie de `iptables-save` et `nft list ruleset` pour être fixé. > [@LePsy666](#): > > Du coté de tcpdump je vois bien la connexion « partir » du client Par quelle interface ? > [@LePsy666](#): > > mais pas arriver sur le serveur Sur quelle interface écoutes-tu ? > [@LePsy666](#): > > le serveur n’a pas d’interface configurée avec l’ip privée Etrange. Tu utilises bien pptpd comme serveur PPTP ? Il devrait créer une interface pppN pour chaque VPN. > [@Zargos](#): > > En fait il reçoit la requete ipv4 et ipv6 si ton pc est en ipv6. De quoi parles-tu ? Il n’y a pas de requête DNS IPv4 et IPv6, mais une requête A (IPv4) et une requête AAAA (IPv6). A moins que ça ait changé, par défaut nslookup fait une requête A, donc ne peut obtenir qu’une adresse IPv4 en retour, et c’est totalement indépendant du fait que le PC est en IPv6 ou pas. ---
**Author:** ![Zargos](https://www.debian-fr.org/user_avatar/www.debian-fr.org/zargos/32/10889_2.png) [@Zargos](https://www.debian-fr.org/u/Zargos)\ **Post date:** [Janvier 25, 2021, 8:28 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/15 "2021-01-25T20:28:19Z")
Sur une machine qui a une ipv4 et une ipv6, si ton routeur internet aussi, quand tu fait ```auto nslookup debian.org ``` il te sort les adresses IPv4 et IPv6 ```auto root@d10srvcdd01:~/simple-cdd# nslookup debian.org Server: *.*.*.* Address: *.*.*.*#53 Non-authoritative answer: Name: debian.org Address: 130.89.148.77 Name: debian.org Address: 149.20.4.15 Name: debian.org Address: 128.31.0.62 Name: debian.org Address: 2603:400a:ffff:bb8::801f:3e Name: debian.org Address: 2001:67c:2564:a119::77 Name: debian.org Address: 2001:4f8:1:c::15 ``` Tu n’as pas à spécifier type A ou AAA. Par contre dig sans préciser répond en IPv4 et host répond comme nslookup en ipv4 et ipv6. ```auto root@d10srvcdd01:~/simple-cdd# dig debian.org ; <<>> DiG 9.16.8-Debian <<>> debian.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24523 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 349b05d47e6708e701000000600f2b1dfb7d136eb77770ec (good) ;; QUESTION SECTION: ;debian.org. IN A ;; ANSWER SECTION: debian.org. 194 IN A 130.89.148.77 debian.org. 194 IN A 128.31.0.62 debian.org. 194 IN A 149.20.4.15 ;; Query time: 12 msec ;; SERVER: *.*.*.*#53(*.*.*.*) ;; WHEN: lun. janv. 25 21:33:33 CET 2021 ;; MSG SIZE rcvd: 115 root@d10srvcdd01:~/simple-cdd# host debian.org debian.org has address 130.89.148.77 debian.org has address 149.20.4.15 debian.org has address 128.31.0.62 debian.org has IPv6 address 2603:400a:ffff:bb8::801f:3e debian.org has IPv6 address 2001:67c:2564:a119::77 debian.org has IPv6 address 2001:4f8:1:c::15 debian.org mail is handled by 0 muffat.debian.org. debian.org mail is handled by 0 mailly.debian.org. ``` ---
**Author:** ![PascalHambourg](https://www.debian-fr.org/user_avatar/www.debian-fr.org/pascalhambourg/32/5837_2.png) [@PascalHambourg](https://www.debian-fr.org/u/PascalHambourg)\ **Post date:** [Janvier 25, 2021, 8:54 UTC](https://www.debian-fr.org/t/vpn-proxy-curl-erreur/83775/16 "2021-01-25T20:54:12Z")
> [@PascalHambourg](#): > > **A moins que ça ait changé** , par défaut nslookup fait une requête A Vérification faite, ça a changé depuis buster. Pour host, c’était déjà le cas depuis longtemps. Par contre ce sont des outils de requête DNS, pas des résolveurs de noms, donc je ne vois pas pourquoi ce serait lié au fait que la machine a une adresse IPv6 ou non. J’ai testé et ce n’est pas le cas.