Pour ceux qui savent d=C3=A9j=C3=A0 tout ce que je vais dire, les question =
sont =C3=A0
la fin du message (num=C3=A9rot=C3=A9es a) et b)). Pour le moment, je dis c=
e que
j'ai fait, ce qui n'a =C3=A0 mon avis rien d'original, c'est juste moi qui
suis long =C3=A0 la comprenette...
Bon, suite =C3=A0 vos conseils et =C3=A0 d'innombrables lectures, je suis a=
rriv=C3=A9
=C3=A0 =C3=A7a :
1- Suppression de NetworkManager, remplac' par systemd.networkd. La
configuration du service :
La connexion fonctionne bien, =C3=A0 travers un PC firewall IPFire en
192.168.10.1.
2- Copie de tous les fichiers de configuration d'openvpn fournis par
HMA (HydeMyAss) dans /etc/openvpn/client, et cr=C3=A9ation d'un lien
HMA.conf vers Belgium.Brussels.UDP.ovpn.
3- Configuration du d=C3=A9mon openvpn@.service avec ce fichier de
configuration :
--> /etc/systemd/system/openvpn@.service.d/override.conf <-- =20
[Unit]
Description=3DOpenVPN connection to %i
After=3Dnetwork.target
Les '\' ne sont bien entendu pas dans le fichiers, c'est juste mon
mailer qui passe tout seul =C3=A0 la ligne. Le double 'ExecStart' me
vient de mes lectures : pour modifier l'ex=C3=A9cutable fourni par le
fichier de configuration par d=C3=A9faut
(dans /lib/systemd/system/openvpn@.service), il faut d'abord vider
la commande fournie, puis la remplacer par une autre, sinon, on se
retrouve avec un message signalant des "ExecStart multiples". La
ligne WorkingDirectory est =C3=A0 mon avis inutile, mais je n'ai pas le
courage de la supprimer.
4- Lancement du serveur openvpn par 'sudo systemctl start openvpn@HMA'.
Joie et bonheur, tout fonctionne... ou presque !
Maintenant, ce qui ne fonctionne pas :
a) comme vous l'avez pu constater, j'ai configur=C3=A9 une (deux, en fait)
routes statiques, parce que Free ne veut pas que j'acc=C3=A8de au serveur
de r=C3=A9cup=C3=A9ration de mails depuis un vpn. Apr=C3=A8s lancement d=
'openvpn@,
je me retrouve avec =C3=A7a dans ma table de routage :
nico@Gaston:/etc/systemd$ ip route
0.0.0.0/1 via 100.120.164.1 dev tun0=20
default via 192.168.10.1 dev enp3s0 proto static=20
5.62.38.15 via 192.168.10.1 dev enp3s0=20
100.120.164.0/22 dev tun0 proto kernel scope link src
100.120.164.245 128.0.0.0/1 via 100.120.164.1 dev tun0=20
192.168.10.0/24 dev enp3s0 proto kernel scope link src 192.168.10.8=20
212.27.48.3 via 192.168.10.1 dev enp3s0 proto static=20
212.27.48.4 via 192.168.10.1 dev enp3s0 proto static=20
Je ne sais pas pourquoi, mais la route par d=C3=A9faut n'est pas
s=C3=A9lectionn=C3=A9e lorsque j'acc=C3=A8de au serveur pop (ou smtp, d'=
ailleurs) de
Free. J'arrive =C3=A0 m'y connecter, mais c'est extr=C3=AAmement lent (de
l'ordre de la minute), et je ne suis pas s=C3=BBr de r=C3=A9cup=C3=A9rer=
quoi que
ce soit. Donc je pense ne pas passer par le bon chemin.
b) Mon firewall (un ordinateur juste derri=C3=A8re la box Free) est configu=
r=C3=A9
pour rediriger 4 ports, pour les applications de p2p. Mais lorsque je
passe par le tunnel, ces ports sont consid=C3=A9r=C3=A9s comme ferm=C3=
=A9s. Je
pense que le fait d'ouvrir un tunnel par openvpn fait que le
firewall ne voit pas les ports concern=C3=A9s par le flux entrant. Je
dois donc, il me semble, configurer le firewall de MON ordinateur,
qui est le seul =C3=A0 savoir que ce flux vient de tun0. Mais je ne sais
pas faire =C3=A7a...
Si vous avez des lumi=C3=A8res sur le sujet, je suis preneur. D'avance un
grand merci.
Et aussi, merci et bravo d'=C3=AAtre arriv=C3=A9 jusque l=C3=A0 !
\bye
--=20
Nicolas FRANCOIS | /\=20
http://nicolas.francois.free.fr | |__|
X--/\\
We are the Micro$oft. _\_V
Resistance is futile. =20
You will be assimilated. darthvader penguin
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Nicolas FRANCOIS
--Sig_/or2j/je77GWt0fO6phgRQ7O Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le Thu, 13 Jul 2017 06:44:25 +0200, "Pierre L." a écrit :
Salut, A mon avis, le fait que tu passes par un VPN obscurcit toutes les connexions à ton firewall. Il ne sait donc pas ce qu'il se passe dans le tuyau (tunnel), c'est un des buts recherchés. Si ton soft de p2p te dit que les ports ne sont pas "ouverts", c'est que de l'autre coté du vpn (l'IP visible par les clients p2p), les ports ne sont pas redirigés comme on le fait d'habitude dans sa box. Imagines que tu passes par mon serveur VPN qui est chez moi, l'internet verra donc mon IP quand tu iras surfer. Idem pour le p2p... mais mon parefeu/routeur ne redirige par tes ports utilisés pour laisser entrer les clients p2p, les clients qui voudraient pomper tes fichiers ne peuvent donc pas entrer car ports bloqués par mon parefeu/routeur. Il faudrait donc que ce soit moi qui fasse le taf de ouverture/redirection de ports. Enfin je vois ca comme ca ;)
Oui, c'est ce que j'ai fini par réaliser, dans mon lit, à 5h du m at, :-) Merci. bye -- Nicolas FRANCOIS | / http://nicolas.francois.free.fr | |__| X--/ We are the Micro$oft. __V Resistance is futile. You will be assimilated. darthvader penguin --Sig_/or2j/je77GWt0fO6phgRQ7O Content-Type: application/pgp-signature Content-Description: Signature digitale OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE7s3+BtBEQX/Kgdk7xYgnps2M/gEFAllnOZwACgkQxYgnps2M /gGAlAgAli/g8/W4cq4SZ17kfLHAp2B3Q1fcBSKBS2zDs/L3FnscJL56iV5tWdKg Xi694Neov3Q+HHf096h/54GyrGGMzCEClfTn9hZKhydAp91GgMNDb8SYycJf2sBn zjmBKsJ1OI+A+m5KXwVTL6FaFJiONl6fmGdTfKPOKslO+JLKo12B6/5OB6Zt2jux 9ac8ORbXqPmZCL/o3ySZb6YsQk7ktxMUhllZtCAkSd8I6p1eIBsPcQg29JWLCN9T Q7flLZjfHgqfL0qUPKgjRhKxG486i3JHNRYRtnRe3AHqkiTD/vUTqdbT5rTmaHaw fLPIXJD7KOEnM7AUZ9WXLsmuXOQR0w= =5rAq -----END PGP SIGNATURE----- --Sig_/or2j/je77GWt0fO6phgRQ7O--
Le Thu, 13 Jul 2017 06:44:25 +0200,
"Pierre L." <petrus@miosweb.mooo.com> a écrit :
Salut,
A mon avis, le fait que tu passes par un VPN obscurcit toutes les
connexions à ton firewall.
Il ne sait donc pas ce qu'il se passe dans le tuyau (tunnel), c'est un
des buts recherchés.
Si ton soft de p2p te dit que les ports ne sont pas "ouverts", c'est
que de l'autre coté du vpn (l'IP visible par les clients p2p), les
ports ne sont pas redirigés comme on le fait d'habitude dans sa box.
Imagines que tu passes par mon serveur VPN qui est chez moi,
l'internet verra donc mon IP quand tu iras surfer. Idem pour le
p2p... mais mon parefeu/routeur ne redirige par tes ports utilisés
pour laisser entrer les clients p2p, les clients qui voudraient
pomper tes fichiers ne peuvent donc pas entrer car ports bloqués par
mon parefeu/routeur. Il faudrait donc que ce soit moi qui fasse le
taf de ouverture/redirection de ports.
Enfin je vois ca comme ca ;)
Oui, c'est ce que j'ai fini par réaliser, dans mon lit, à 5h du m at, :-)
Merci.
bye
--
Nicolas FRANCOIS | /
http://nicolas.francois.free.fr | |__|
X--/\
We are the Micro$oft. __V
Resistance is futile.
You will be assimilated. darthvader penguin
--Sig_/or2j/je77GWt0fO6phgRQ7O Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le Thu, 13 Jul 2017 06:44:25 +0200, "Pierre L." a écrit :
Salut, A mon avis, le fait que tu passes par un VPN obscurcit toutes les connexions à ton firewall. Il ne sait donc pas ce qu'il se passe dans le tuyau (tunnel), c'est un des buts recherchés. Si ton soft de p2p te dit que les ports ne sont pas "ouverts", c'est que de l'autre coté du vpn (l'IP visible par les clients p2p), les ports ne sont pas redirigés comme on le fait d'habitude dans sa box. Imagines que tu passes par mon serveur VPN qui est chez moi, l'internet verra donc mon IP quand tu iras surfer. Idem pour le p2p... mais mon parefeu/routeur ne redirige par tes ports utilisés pour laisser entrer les clients p2p, les clients qui voudraient pomper tes fichiers ne peuvent donc pas entrer car ports bloqués par mon parefeu/routeur. Il faudrait donc que ce soit moi qui fasse le taf de ouverture/redirection de ports. Enfin je vois ca comme ca ;)
Oui, c'est ce que j'ai fini par réaliser, dans mon lit, à 5h du m at, :-) Merci. bye -- Nicolas FRANCOIS | / http://nicolas.francois.free.fr | |__| X--/ We are the Micro$oft. __V Resistance is futile. You will be assimilated. darthvader penguin --Sig_/or2j/je77GWt0fO6phgRQ7O Content-Type: application/pgp-signature Content-Description: Signature digitale OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE7s3+BtBEQX/Kgdk7xYgnps2M/gEFAllnOZwACgkQxYgnps2M /gGAlAgAli/g8/W4cq4SZ17kfLHAp2B3Q1fcBSKBS2zDs/L3FnscJL56iV5tWdKg Xi694Neov3Q+HHf096h/54GyrGGMzCEClfTn9hZKhydAp91GgMNDb8SYycJf2sBn zjmBKsJ1OI+A+m5KXwVTL6FaFJiONl6fmGdTfKPOKslO+JLKo12B6/5OB6Zt2jux 9ac8ORbXqPmZCL/o3ySZb6YsQk7ktxMUhllZtCAkSd8I6p1eIBsPcQg29JWLCN9T Q7flLZjfHgqfL0qUPKgjRhKxG486i3JHNRYRtnRe3AHqkiTD/vUTqdbT5rTmaHaw fLPIXJD7KOEnM7AUZ9WXLsmuXOQR0w= =5rAq -----END PGP SIGNATURE----- --Sig_/or2j/je77GWt0fO6phgRQ7O--
Pierre L.
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CBS5UrswAP9Bo1674qwXLcstn7TPlxsP7 Content-Type: multipart/mixed; boundary="vtaBDMTg2kK1sLL0R2twEorVDdJ0hATDV"; protected-headers="v1" From: "Pierre L." To: Message-ID: Subject: =?UTF-8?Q?Re:_Configuration_réseau,_le_retour_et_des_pistes_? =?UTF-8?Q?!? References:
In-Reply-To: --vtaBDMTg2kK1sLL0R2twEorVDdJ0hATDV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: fr Donc configuration du coté serveur VPN pour redirection des ports en entrée vers ton IP du tunnel ? C'est bien ca ? Le 13/07/2017 à 11:13, Nicolas FRANCOIS a écrit :
Oui, c'est ce que j'ai fini par réaliser, dans mon lit, à 5h du mat,
This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --CBS5UrswAP9Bo1674qwXLcstn7TPlxsP7 Content-Type: multipart/mixed; boundary="vtaBDMTg2kK1sLL0R2twEorVDdJ0hATDV"; protected-headers="v1" From: "Pierre L." To: Message-ID: Subject: =?UTF-8?Q?Re:_Configuration_réseau,_le_retour_et_des_pistes_? =?UTF-8?Q?!? References:
In-Reply-To: --vtaBDMTg2kK1sLL0R2twEorVDdJ0hATDV Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: fr Donc configuration du coté serveur VPN pour redirection des ports en entrée vers ton IP du tunnel ? C'est bien ca ? Le 13/07/2017 à 11:13, Nicolas FRANCOIS a écrit :
Oui, c'est ce que j'ai fini par réaliser, dans mon lit, à 5h du mat,
--Sig_/W7Ocg94NFHSdRZFQqzjLkmr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le Thu, 13 Jul 2017 15:46:46 +0200, "Pierre L." a écrit :
Donc configuration du coté serveur VPN pour redirection des ports en entrée vers ton IP du tunnel ? C'est bien ca ? Le 13/07/2017 à 11:13, Nicolas FRANCOIS a écrit :
Oui, c'est ce que j'ai fini par réaliser, dans mon lit, à 5h du mat,
Voui. Maintenant, je ne sais pas comment faire, faut que je demande à HMA ! bye PS : ça m'apprendra : quand on pose deux questions sur une liste de diffusion, on ne reçoit jamais que la réponse à une seule... alors que l'autre question m'enquiquine pas mal :-( Je vais faire un autre fil ! -- Nicolas FRANCOIS | / http://nicolas.francois.free.fr | |__| X--/ We are the Micro$oft. __V Resistance is futile. You will be assimilated. darthvader penguin --Sig_/W7Ocg94NFHSdRZFQqzjLkmr Content-Type: application/pgp-signature Content-Description: Signature digitale OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE7s3+BtBEQX/Kgdk7xYgnps2M/gEFAllnht4ACgkQxYgnps2M /gECmQf/RHT+9pEzzhlGlWZRkWDOXzdxxI49E63K4fgzgEeIt2+wHxLBdYtsPazU Iqe9bWcQuVLP/ljfJkAJN+D1wH8MPVAqswzZgCOYLs/+P2/k0cOqyxy/n+Em/u0f CUbpEG3CMgfOy9mDd4cLtEyuM7opTrw5X5lKaEX/6WestP4BHUXZaDoqYEzGEjXY OufNUIstM3+gYUoTsd1Jghm/qmVkpghqm8lGY9bS6ETo53BSPzSHWRIq/8W9WBmh zOtX3PxdR2iuuNig4oy6pEy2OvhWfcEn8kBvcYaOuI7QTP3DbzmBiH1JdwXzI2kI fpdgAbJI9LoOGiTbVLxNaspXwZpSrQ= cC -----END PGP SIGNATURE----- --Sig_/W7Ocg94NFHSdRZFQqzjLkmr--
Le Thu, 13 Jul 2017 15:46:46 +0200,
"Pierre L." <petrus@miosweb.mooo.com> a écrit :
Donc configuration du coté serveur VPN pour redirection des ports en
entrée vers ton IP du tunnel ? C'est bien ca ?
Le 13/07/2017 à 11:13, Nicolas FRANCOIS a écrit :
> Oui, c'est ce que j'ai fini par réaliser, dans mon lit, à 5h du
> mat,
Voui. Maintenant, je ne sais pas comment faire, faut que je demande à
HMA !
bye
PS : ça m'apprendra : quand on pose deux questions sur une liste de
diffusion, on ne reçoit jamais que la réponse à une seule... alors que
l'autre question m'enquiquine pas mal :-( Je vais faire un autre fil !
--
Nicolas FRANCOIS | /
http://nicolas.francois.free.fr | |__|
X--/\
We are the Micro$oft. __V
Resistance is futile.
You will be assimilated. darthvader penguin
--Sig_/W7Ocg94NFHSdRZFQqzjLkmr Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Le Thu, 13 Jul 2017 15:46:46 +0200, "Pierre L." a écrit :
Donc configuration du coté serveur VPN pour redirection des ports en entrée vers ton IP du tunnel ? C'est bien ca ? Le 13/07/2017 à 11:13, Nicolas FRANCOIS a écrit :
Oui, c'est ce que j'ai fini par réaliser, dans mon lit, à 5h du mat,
Voui. Maintenant, je ne sais pas comment faire, faut que je demande à HMA ! bye PS : ça m'apprendra : quand on pose deux questions sur une liste de diffusion, on ne reçoit jamais que la réponse à une seule... alors que l'autre question m'enquiquine pas mal :-( Je vais faire un autre fil ! -- Nicolas FRANCOIS | / http://nicolas.francois.free.fr | |__| X--/ We are the Micro$oft. __V Resistance is futile. You will be assimilated. darthvader penguin --Sig_/W7Ocg94NFHSdRZFQqzjLkmr Content-Type: application/pgp-signature Content-Description: Signature digitale OpenPGP -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEE7s3+BtBEQX/Kgdk7xYgnps2M/gEFAllnht4ACgkQxYgnps2M /gECmQf/RHT+9pEzzhlGlWZRkWDOXzdxxI49E63K4fgzgEeIt2+wHxLBdYtsPazU Iqe9bWcQuVLP/ljfJkAJN+D1wH8MPVAqswzZgCOYLs/+P2/k0cOqyxy/n+Em/u0f CUbpEG3CMgfOy9mDd4cLtEyuM7opTrw5X5lKaEX/6WestP4BHUXZaDoqYEzGEjXY OufNUIstM3+gYUoTsd1Jghm/qmVkpghqm8lGY9bS6ETo53BSPzSHWRIq/8W9WBmh zOtX3PxdR2iuuNig4oy6pEy2OvhWfcEn8kBvcYaOuI7QTP3DbzmBiH1JdwXzI2kI fpdgAbJI9LoOGiTbVLxNaspXwZpSrQ= cC -----END PGP SIGNATURE----- --Sig_/W7Ocg94NFHSdRZFQqzjLkmr--
Pascal Hambourg
Le 13/07/2017 à 02:26, Nicolas FRANCOIS a écrit :
a) comme vous l'avez pu constater, j'ai configuré une (deux, en fait) routes statiques, parce que Free ne veut pas que j'accède au serveur de récupération de mails depuis un vpn. Après lancement d'openvpn@, je me retrouve avec ça dans ma table de routage : :/etc/systemd$ ip route 0.0.0.0/1 via 100.120.164.1 dev tun0 default via 192.168.10.1 dev enp3s0 proto static 5.62.38.15 via 192.168.10.1 dev enp3s0 100.120.164.0/22 dev tun0 proto kernel scope link src 100.120.164.245 128.0.0.0/1 via 100.120.164.1 dev tun0 192.168.10.0/24 dev enp3s0 proto kernel scope link src 192.168.10.8 212.27.48.3 via 192.168.10.1 dev enp3s0 proto static 212.27.48.4 via 192.168.10.1 dev enp3s0 proto static
Normal.
Je ne sais pas pourquoi, mais la route par défaut n'est pas sélectionnée lorsque j'accède au serveur pop (ou smtp, d'ailleurs) de Free. J'arrive à m'y connecter, mais c'est extrêmement lent (de l'ordre de la minute), et je ne suis pas sûr de récupérer quoi que ce soit. Donc je pense ne pas passer par le bon chemin.
Pour vérifier le routage d'une destination, tu peux utiliser la commande "ip route get $DEST". Sauf si tu as mis en place du routage avancé (ip rule) mais tu l'aurais dit. Les deux adresses pour lesquelles tu as créé des routes spécifiques correspondent à smtp.free.fr et pop.free.fr. Ton client mail fait-il bien la relève du courrier depuis le serveur POP et non depuis le serveur IMAP imap.free.fr pour l'adresse duquel tu n'as pas créé de route ? D'autre part, ces serveurs ont aussi une adresse IPv6. Si ton logiciel client de messagerie supporte IPv6, si le serveur est défini par son nom et non son adresse IP, si la machine a ou croit avoir une connectivité IPv6 et si le serveur DNS interrogé supporte les enregistrements d'adresse IPv6, alors par défaut le client essaiera de se connecter au serveur en IPv6 en premier. Si la connexion échoue par dépassement du délai de réponse, il réessaiera en IPv4. Il me semble avoir vu dans un de tes précédents messages que le VPN poussait sur tun0 une route vers 2000::/3 (préfixe IPv6 global unicast actuel) et une adresse et un préfixe IPv6 de la plage 2001.db8::/32. Or cette plage d'adresses est réservée aux exemples et à la documentation, donc je me demande si le VPN fournit vraiment une connectivité IPv6. Tu peux vérifier la configuration IPv6 avec "ip -6 addr" et "ip -6 route", et tester la connectivité avec des commandes comme ping6 et traceroute6. Un de mes serveurs de test favoris est nic.fr qui répond aussi bien en IPv4 qu'en IPv6. Même si c'est le cas à travers du NAT66 (quel gâchis, l'IPv6 était censé éviter le NAT), il se peut que la plage IPv6 publique du VPN soit blacklistée par les serveurs de Free au même titre que sa plage IPv4. Si tu as activé l'IPv6 sur ta Freebox et l'a laissé passer à travers ton firewall, tu peux ajouter des routes IPv6 statiques pour les adresses IPv6 des serveurs de courrier de Free. smtp.free.fr has IPv6 address 2a01:e0c:1::25 pop.free.fr has IPv6 address 2a01:e0c:1::110 imap.free.fr has IPv6 address 2a01:e0c:1::143
Le 13/07/2017 à 02:26, Nicolas FRANCOIS a écrit :
a) comme vous l'avez pu constater, j'ai configuré une (deux, en fait)
routes statiques, parce que Free ne veut pas que j'accède au serveur
de récupération de mails depuis un vpn. Après lancement d'openvpn@,
je me retrouve avec ça dans ma table de routage :
nico@Gaston:/etc/systemd$ ip route
0.0.0.0/1 via 100.120.164.1 dev tun0
default via 192.168.10.1 dev enp3s0 proto static
5.62.38.15 via 192.168.10.1 dev enp3s0
100.120.164.0/22 dev tun0 proto kernel scope link src 100.120.164.245
128.0.0.0/1 via 100.120.164.1 dev tun0
192.168.10.0/24 dev enp3s0 proto kernel scope link src 192.168.10.8
212.27.48.3 via 192.168.10.1 dev enp3s0 proto static
212.27.48.4 via 192.168.10.1 dev enp3s0 proto static
Normal.
Je ne sais pas pourquoi, mais la route par défaut n'est pas
sélectionnée lorsque j'accède au serveur pop (ou smtp, d'ailleurs) de
Free. J'arrive à m'y connecter, mais c'est extrêmement lent (de
l'ordre de la minute), et je ne suis pas sûr de récupérer quoi que
ce soit. Donc je pense ne pas passer par le bon chemin.
Pour vérifier le routage d'une destination, tu peux utiliser la commande
"ip route get $DEST". Sauf si tu as mis en place du routage avancé (ip
rule) mais tu l'aurais dit.
Les deux adresses pour lesquelles tu as créé des routes spécifiques
correspondent à smtp.free.fr et pop.free.fr. Ton client mail fait-il
bien la relève du courrier depuis le serveur POP et non depuis le
serveur IMAP imap.free.fr pour l'adresse duquel tu n'as pas créé de route ?
D'autre part, ces serveurs ont aussi une adresse IPv6. Si ton logiciel
client de messagerie supporte IPv6, si le serveur est défini par son nom
et non son adresse IP, si la machine a ou croit avoir une connectivité
IPv6 et si le serveur DNS interrogé supporte les enregistrements
d'adresse IPv6, alors par défaut le client essaiera de se connecter au
serveur en IPv6 en premier. Si la connexion échoue par dépassement du
délai de réponse, il réessaiera en IPv4.
Il me semble avoir vu dans un de tes précédents messages que le VPN
poussait sur tun0 une route vers 2000::/3 (préfixe IPv6 global unicast
actuel) et une adresse et un préfixe IPv6 de la plage 2001.db8::/32. Or
cette plage d'adresses est réservée aux exemples et à la documentation,
donc je me demande si le VPN fournit vraiment une connectivité IPv6.
Tu peux vérifier la configuration IPv6 avec "ip -6 addr" et "ip -6
route", et tester la connectivité avec des commandes comme ping6 et
traceroute6. Un de mes serveurs de test favoris est nic.fr qui répond
aussi bien en IPv4 qu'en IPv6.
Même si c'est le cas à travers du NAT66 (quel gâchis, l'IPv6 était censé
éviter le NAT), il se peut que la plage IPv6 publique du VPN soit
blacklistée par les serveurs de Free au même titre que sa plage IPv4.
Si tu as activé l'IPv6 sur ta Freebox et l'a laissé passer à travers ton
firewall, tu peux ajouter des routes IPv6 statiques pour les adresses
IPv6 des serveurs de courrier de Free.
smtp.free.fr has IPv6 address 2a01:e0c:1::25
pop.free.fr has IPv6 address 2a01:e0c:1::110
imap.free.fr has IPv6 address 2a01:e0c:1::143
a) comme vous l'avez pu constater, j'ai configuré une (deux, en fait) routes statiques, parce que Free ne veut pas que j'accède au serveur de récupération de mails depuis un vpn. Après lancement d'openvpn@, je me retrouve avec ça dans ma table de routage : :/etc/systemd$ ip route 0.0.0.0/1 via 100.120.164.1 dev tun0 default via 192.168.10.1 dev enp3s0 proto static 5.62.38.15 via 192.168.10.1 dev enp3s0 100.120.164.0/22 dev tun0 proto kernel scope link src 100.120.164.245 128.0.0.0/1 via 100.120.164.1 dev tun0 192.168.10.0/24 dev enp3s0 proto kernel scope link src 192.168.10.8 212.27.48.3 via 192.168.10.1 dev enp3s0 proto static 212.27.48.4 via 192.168.10.1 dev enp3s0 proto static
Normal.
Je ne sais pas pourquoi, mais la route par défaut n'est pas sélectionnée lorsque j'accède au serveur pop (ou smtp, d'ailleurs) de Free. J'arrive à m'y connecter, mais c'est extrêmement lent (de l'ordre de la minute), et je ne suis pas sûr de récupérer quoi que ce soit. Donc je pense ne pas passer par le bon chemin.
Pour vérifier le routage d'une destination, tu peux utiliser la commande "ip route get $DEST". Sauf si tu as mis en place du routage avancé (ip rule) mais tu l'aurais dit. Les deux adresses pour lesquelles tu as créé des routes spécifiques correspondent à smtp.free.fr et pop.free.fr. Ton client mail fait-il bien la relève du courrier depuis le serveur POP et non depuis le serveur IMAP imap.free.fr pour l'adresse duquel tu n'as pas créé de route ? D'autre part, ces serveurs ont aussi une adresse IPv6. Si ton logiciel client de messagerie supporte IPv6, si le serveur est défini par son nom et non son adresse IP, si la machine a ou croit avoir une connectivité IPv6 et si le serveur DNS interrogé supporte les enregistrements d'adresse IPv6, alors par défaut le client essaiera de se connecter au serveur en IPv6 en premier. Si la connexion échoue par dépassement du délai de réponse, il réessaiera en IPv4. Il me semble avoir vu dans un de tes précédents messages que le VPN poussait sur tun0 une route vers 2000::/3 (préfixe IPv6 global unicast actuel) et une adresse et un préfixe IPv6 de la plage 2001.db8::/32. Or cette plage d'adresses est réservée aux exemples et à la documentation, donc je me demande si le VPN fournit vraiment une connectivité IPv6. Tu peux vérifier la configuration IPv6 avec "ip -6 addr" et "ip -6 route", et tester la connectivité avec des commandes comme ping6 et traceroute6. Un de mes serveurs de test favoris est nic.fr qui répond aussi bien en IPv4 qu'en IPv6. Même si c'est le cas à travers du NAT66 (quel gâchis, l'IPv6 était censé éviter le NAT), il se peut que la plage IPv6 publique du VPN soit blacklistée par les serveurs de Free au même titre que sa plage IPv4. Si tu as activé l'IPv6 sur ta Freebox et l'a laissé passer à travers ton firewall, tu peux ajouter des routes IPv6 statiques pour les adresses IPv6 des serveurs de courrier de Free. smtp.free.fr has IPv6 address 2a01:e0c:1::25 pop.free.fr has IPv6 address 2a01:e0c:1::110 imap.free.fr has IPv6 address 2a01:e0c:1::143
Pascal Hambourg
Le 13/07/2017 à 06:44, Pierre L. a écrit :
Si ton soft de p2p te dit que les ports ne sont pas "ouverts", c'est que de l'autre coté du vpn (l'IP visible par les clients p2p), les ports ne sont pas redirigés comme on le fait d'habitude dans sa box.
C'est surtout que le fournisseur de VPN ne fournit pas une connectivité internet complète avec une adresse IP publique propre mais juste une adresse IP privée avec du NAT, donc une demi-connectivité internet.
Imagines que tu passes par mon serveur VPN qui est chez moi, l'internet verra donc mon IP quand tu iras surfer. Idem pour le p2p... mais mon parefeu/routeur ne redirige par tes ports utilisés pour laisser entrer les clients p2p
Ce n'est pas une généralité. Avec mon serveur VPN, il aurait une adresse IP publique propre et une connectivité internet complète sans NAT ni redirection de ports. Bref, bien choisir son fournisseur de VPN pour ses besoins.
Le 13/07/2017 à 06:44, Pierre L. a écrit :
Si ton soft de p2p te dit que les ports ne sont pas "ouverts", c'est que
de l'autre coté du vpn (l'IP visible par les clients p2p), les ports ne
sont pas redirigés comme on le fait d'habitude dans sa box.
C'est surtout que le fournisseur de VPN ne fournit pas une connectivité
internet complète avec une adresse IP publique propre mais juste une
adresse IP privée avec du NAT, donc une demi-connectivité internet.
Imagines que tu passes par mon serveur VPN qui est chez moi, l'internet
verra donc mon IP quand tu iras surfer. Idem pour le p2p... mais mon
parefeu/routeur ne redirige par tes ports utilisés pour laisser entrer
les clients p2p
Ce n'est pas une généralité. Avec mon serveur VPN, il aurait une adresse
IP publique propre et une connectivité internet complète sans NAT ni
redirection de ports.
Bref, bien choisir son fournisseur de VPN pour ses besoins.
Si ton soft de p2p te dit que les ports ne sont pas "ouverts", c'est que de l'autre coté du vpn (l'IP visible par les clients p2p), les ports ne sont pas redirigés comme on le fait d'habitude dans sa box.
C'est surtout que le fournisseur de VPN ne fournit pas une connectivité internet complète avec une adresse IP publique propre mais juste une adresse IP privée avec du NAT, donc une demi-connectivité internet.
Imagines que tu passes par mon serveur VPN qui est chez moi, l'internet verra donc mon IP quand tu iras surfer. Idem pour le p2p... mais mon parefeu/routeur ne redirige par tes ports utilisés pour laisser entrer les clients p2p
Ce n'est pas une généralité. Avec mon serveur VPN, il aurait une adresse IP publique propre et une connectivité internet complète sans NAT ni redirection de ports. Bref, bien choisir son fournisseur de VPN pour ses besoins.
Pascal Hambourg
Le 14/07/2017 à 10:21, Pierre L. a écrit :
Je pensais qu'un accès VPN nous créait seulement un tuyau pour arriver bêtement dans un autre LAN, qui se trouve protégé derrière un modem/routeur type box de FAI...
Non, pas forcément. Ça peut être un vrai routeur comme les routeurs d'agrégation des FAI.
En gros il doit y avoir des règles de routage qui disent que tout le trafic est automatiquement envoyé vers l'IP du client VPN ?
Si le client a une adresse IP publique propre, pas besoin de règles de routage ; les routes normales suffisent.
Le 14/07/2017 à 10:11, Pascal Hambourg a écrit :
Le 13/07/2017 à 06:44, Pierre L. a écrit :
Si ton soft de p2p te dit que les ports ne sont pas "ouverts", c'est que de l'autre coté du vpn (l'IP visible par les clients p2p), les ports ne sont pas redirigés comme on le fait d'habitude dans sa box.
C'est surtout que le fournisseur de VPN ne fournit pas une connectivité internet complète avec une adresse IP publique propre mais juste une adresse IP privée avec du NAT, donc une demi-connectivité internet.
Imagines que tu passes par mon serveur VPN qui est chez moi, l'internet verra donc mon IP quand tu iras surfer. Idem pour le p2p... mais mon parefeu/routeur ne redirige par tes ports utilisés pour laisser entrer les clients p2p
Ce n'est pas une généralité. Avec mon serveur VPN, il aurait une adresse IP publique propre et une connectivité internet complète sans NAT ni redirection de ports. Bref, bien choisir son fournisseur de VPN pour ses besoins.
Le 14/07/2017 à 10:21, Pierre L. a écrit :
Je pensais qu'un accès VPN nous créait seulement un tuyau pour arriver
bêtement dans un autre LAN, qui se trouve protégé derrière un
modem/routeur type box de FAI...
Non, pas forcément. Ça peut être un vrai routeur comme les routeurs
d'agrégation des FAI.
En gros il doit y avoir des règles de routage qui disent que tout le
trafic est automatiquement envoyé vers l'IP du client VPN ?
Si le client a une adresse IP publique propre, pas besoin de règles de
routage ; les routes normales suffisent.
Le 14/07/2017 à 10:11, Pascal Hambourg a écrit :
Le 13/07/2017 à 06:44, Pierre L. a écrit :
Si ton soft de p2p te dit que les ports ne sont pas "ouverts", c'est que
de l'autre coté du vpn (l'IP visible par les clients p2p), les ports ne
sont pas redirigés comme on le fait d'habitude dans sa box.
C'est surtout que le fournisseur de VPN ne fournit pas une
connectivité internet complète avec une adresse IP publique propre
mais juste une adresse IP privée avec du NAT, donc une
demi-connectivité internet.
Imagines que tu passes par mon serveur VPN qui est chez moi, l'internet
verra donc mon IP quand tu iras surfer. Idem pour le p2p... mais mon
parefeu/routeur ne redirige par tes ports utilisés pour laisser entrer
les clients p2p
Ce n'est pas une généralité. Avec mon serveur VPN, il aurait une
adresse IP publique propre et une connectivité internet complète sans
NAT ni redirection de ports.
Bref, bien choisir son fournisseur de VPN pour ses besoins.
Je pensais qu'un accès VPN nous créait seulement un tuyau pour arriver bêtement dans un autre LAN, qui se trouve protégé derrière un modem/routeur type box de FAI...
Non, pas forcément. Ça peut être un vrai routeur comme les routeurs d'agrégation des FAI.
En gros il doit y avoir des règles de routage qui disent que tout le trafic est automatiquement envoyé vers l'IP du client VPN ?
Si le client a une adresse IP publique propre, pas besoin de règles de routage ; les routes normales suffisent.
Le 14/07/2017 à 10:11, Pascal Hambourg a écrit :
Le 13/07/2017 à 06:44, Pierre L. a écrit :
Si ton soft de p2p te dit que les ports ne sont pas "ouverts", c'est que de l'autre coté du vpn (l'IP visible par les clients p2p), les ports ne sont pas redirigés comme on le fait d'habitude dans sa box.
C'est surtout que le fournisseur de VPN ne fournit pas une connectivité internet complète avec une adresse IP publique propre mais juste une adresse IP privée avec du NAT, donc une demi-connectivité internet.
Imagines que tu passes par mon serveur VPN qui est chez moi, l'internet verra donc mon IP quand tu iras surfer. Idem pour le p2p... mais mon parefeu/routeur ne redirige par tes ports utilisés pour laisser entrer les clients p2p
Ce n'est pas une généralité. Avec mon serveur VPN, il aurait une adresse IP publique propre et une connectivité internet complète sans NAT ni redirection de ports. Bref, bien choisir son fournisseur de VPN pour ses besoins.
