VPN + Proxy + curl = erreur

Support Debian
, ,
Tags: #<Tag:0x00007f63e626d300> #<Tag:0x00007f63e626d210> #<Tag:0x00007f63e626d148>
#1

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

curl: (35) OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to www.google.fr:443

et en http

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.

#2

Il est possible que ce soit lié à l’IPv6. en fait quadn tu fait www.google.fr:443, l’ip de www.google.fr est une ipv6.
Ta machine doit traiter l’IPv6 en priorité à l’IPv4.

#3

Question bête, que donne comme résultat la même commande exécutée sur le serveur VPN ?

#4

Ca ne semble pas venir de la, j’ai testé sur un site en ipv4 et j’ai le même souci :

[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 )

#5

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é.

#6

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
#7

Ca ne sort pas d’ip v6 depuis mon serveur VPN :

[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 :slight_smile:

#8

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?

#9

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 <=> 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 !

#10

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?

Tu parles de la route indiquée?

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.

#11

Ce n’est pas un proxy, c’est un routeur NAT. Ou alors tu ne nous dis pas tout.

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.

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

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 ?

#12

:slight_smile: 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 !

#13

En fait il reçoit la requete ipv4 et ipv6 si ton pc est en ipv6.

#14

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é.

Par quelle interface ?

Sur quelle interface écoutes-tu ?

Etrange. Tu utilises bien pptpd comme serveur PPTP ? Il devrait créer une interface pppN pour chaque VPN.

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.

#15

Sur une machine qui a une ipv4 et une ipv6, si ton routeur internet aussi, quand tu fait

nslookup debian.org

il te sort les adresses IPv4 et IPv6

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.

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.
#16

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.