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 !
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.
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 )
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é.
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
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?
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.
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.
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 ?
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.
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.
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.
