Bonjour,
 
Je rencontre un problème que je n'arrive pas à résoudre (par manque de connaissance probablement en matière de DNS) suite à la mise en place d'un routeur asus rt-n66u et d'un accès vpn chez HideMyAss.
 
Avant, j'avais un petit réseau de 2 postes W7 pro et un nas synology dérrière une freebox v5 avec une IP fixe publique 82.137.356.xxx. Le nas synology héberge un serveur de messagerie (via l'application mail server de synology) de mon domaine pris chez bookmyname. Chez Bookmyname, j'ai personnalisé le contenu de mes DNS pour renvoyer le trafic vers l'IP fixe publique 82.137.356.xxx fournie par Free. Sur la freebox, j'ai fait une redirection de port vers l'adresse IP locale du nas synology. Tout fonctionnait correctement. J'arrivais à recevoir et envoyer des messages avec mon nom de domaine.
 
J'ai voulu sécuriser mes échanges sur Internet en me connectant via un serveur VPN. J'ai choisis  HideMyAss au vu des bons commentaires sur différents articles et forums. Pour faire simple dans l'installation, gérer automatiquement tout le trafic réseau filaire et wifi et aussi pour être indépendant de la FAIbox en cas de changements, j'ai choisi de mettre en place un routeur asus rt-n66u. J'ai mis la freebox v5 en mode modem uniquement (j'ai enlevé le mode routeur et le wifi) et configurer le routeur  asus rt-n66u, le client VPN et fait les redirections de ports identiques à la freebox.
 
Mon problème : lorsque le routeur asus rt-n66u VPN est connecté, l'adresse IP publique est différente (ce qui normal, c'est aussi le but du jeu). L'adresse IP Wan du routeur asus rt-n66u reste cependant 82.137.356.xxx. L'emission et la réception des messages de mon domaine enregistré chez bookmyname et hébergé sur mon nas synology ne fonctionne pas. Lorsque je déconnecte le VPN, l'adresse IP publique redevient 82.137.356.xxx. Et là, l'emission et la réception des messages de mon domaine fonctionne de nouveau. Je vois bien que le problème semble lié à l'adresse IP publique mais je ne vois pas comment le résoudre. J'ai essayé avec No-IP mais je ne dois pas m'y prendre correctement non plus. Cela ne fonctionne pas non plus. Je tourne le problème dans tous les sens depuis plusieurs jours mais sans résultat. Si quelqu'un pouvait me donner un petit coup de main, ce serait sympa et je lui en serais reconnaissant.
 
Vous remerciant de votre aide.

Si j'essaye de t'envoyer un message quand ton vpn est connecté.
Le DNS doit me renvoyer ton ip 82.x comme serveur de messagerie.
Mais le routeur Asus refuse le message car le routeur doit-être réglé pour faire passer tout le trafic (entrant-sortant) par le vpn.
Il faudrait voir s'il est possible d'autoriser le trafic entrant sans qu'il passe par le vpn.
Car le chemin que les mails vont emprunter pour arriver chez toi sera direct et ils chercheront pas à savoir si tu as un vpn
 
Pour l'envoi de mail, il y a plusieurs possibilités.
Soit tes messages sont envoyés par un SMTP.
Soit ils sont envoyés directement sur internet.
il faudra voir les messages d'erreur que tu reçois quand tu envoies un mail.
Tu peux configurer un outlook sur ton poste pour faire un test.

Bonjour et merci de votre aide,
 
 
 
Je ne vois pas comment faire cela ???  
 
Le plus simple ne serait pas de considérer l'IP du VPN comme dynamique (ce qui sera le cas dans les faits car je vais changer de serveur toutes les semaines) et mettre en place un service de DNS dynamique ? J'ai essayé avec no-ip mais je ne comprends pas bien comment cela fonctionne. Cela semble particulier notamment pour les enregistrements MX.
 
 
 
Les messages sont envoyés par SMTP. Autant je comprends pour les mails entrants que la nouvelle adresse IP du VPN perturbe la réception, autant pour les mails sortants ??? J'ai thunderbird sur les 2 postes. Lorsque j'envoie un mail avec ce domaine et thunderbird, tout se passe normalement. Il part bien, je présume car figure dans les mails envoyés après envoi mais rien chez le destinataire (une autre adresse mail chez google que je consulte en imap avec thunderbird). Aucun message d'erreur. Il semble partir dans la nature.
 
Ce qui est marrant (enfin ça ne me fait plus rire), c'est que lorsque je déconnecte le VPN tout fonctionne normalement en émission et réception.
 
Vous remerciant de votre aide.

la messagerie MX a besoin d'une ip fixe pour fonctionner.
 
C'est étrange qu'il n'y ait aucun message d'erreur.

 
Il n'y a pas moyen alors d'héberger un serveur de messagerie lorsqu'on a une IP dynamique ? Bizarre, il me semble avoir vu un enregistrement MX chez no-IP.com. Je me trompe peut être.  
 
 
 
En émission, aucun. En revanche lorque j'envoie un mail de mon adresse chez google sur celle de mon domaine, je viens de recevoir un message d'erreur de google :

 
Vous remerciant de votre aide.

Pour une messagerie, tu as besoin de fiabilité, tu ne peux pas te permettre de recevoir 1 message sur 2.
Donc l'ip dynamique est à proscrire
 
Tu peux essayer la doc du vpn pour la messagerie
https://meilleurvpn.net/4767/commen [...] -securite/

Re,
 
Merci pour le lien de la doc.  
 
J'en comprends qu'il faut faire ajouter mon nom de domaine sur la liste blanche smtp de HMA. C'est bien cela ? (car je ne veux pas héberger mes mails chez google ou MS)  
 
Il faut donc que je maintienne l'IP WAN fixe fournie par FREE dans les enregistrements DNS du domaine (et non l'IP publique fournie par le serveur VPN) ?  
 
je vais essayer auprès de HMA voir si cela me débloque l'émission et la réception des mails de mon domaine. Ca ne peut pas faire de mal.
 
Te remerciant de ton aide.

Re,
 
J'ai fait ajouter hier mon nom de domaine à la liste blanche smtp de HMA. Toujours la même chose. Pas d'émission et de réception lorsque le client  VPN du routeur est connecté à un serveur de HMA. Dans le doute, j'en ai essayé plusieurs en TCP et en UDP mais rien à faire. Dés que je déconnecte, tout fonctionne normalement. Un truc de fou (en tout cas pour moi).
 
Si quelqu'un a une idée pour me sortir de ce b.rd.l qui  me prend la tête depuis des jours, je suis preneur.
 
Vous remerciant de votre aide.

Je dis ça comme ça mais la plupart des sorties VPN sont dans des listes noires de SPAM pour des raisons évidentes.
Et celles qui ne le sont pas bloquent le SMTP en sortie pour éviter de l'être.
 
De plus il faut qu'il y ait un reverse DNS fonctionnel et valide sur l'IP de sortie pour qu'elle soit trustée par les autres serveurs de messagerie sinon les mails seront systématiquement refusés.
 
 
Mais plus simplement, rends-toi service, dégage ce VPN dont tu n'as aucune utilité.
Le matraquage pseudo-sécuritaire des services VPN c'est la plus grande connerie de ces dernières années.
La réalité c'est que tu paies en réalité pour un service qui facilite l'interception de tes données - métadonnées ainsi que ton trafic - par une entité tierce qui au mieux te ment en te faisant croire qu'ils ne conservent rien sur toi alors que la législation européenne les oblige à le faire et au pire échappent totalement à cette législation et il n'y a donc aucun recours en cas de problème et tu t'exposes donc au vol de tes mots de passe, données bancaires, phishing, malware, et autres joyeusetés...
Dans la réalité toujours des cas d'interception de trafic, vol de mots de passe et de données bancaires pourraient avoir pour origine ce genre de services VPN à cause de malversation internes car il est très facile d’intercepter ou d'altérer le trafic d'un utilisateur car ce qui est peu dit c'est que prêt du tiers des vols de données personnelles et bancaires ne sont pas le fruit d'un piratage externe mais bien le fait de malversation internes et d'employés peu scrupuleux.
 
Un VPN ne devrait être utilisé que pour se connecter à son propre réseau interne ou pour accéder à internet depuis un accès internet qui n'est pas de confiance, tout le reste c'est de la pure connerie.

Si je comprends bien, il n'y a donc pas moyen de faire fonctionner correctement un serveur de messagerie derrière un serveur VPN fourni par des prestataires en la matière ? J'ai interrogé l'assistance de HMA. J'attends leur réponse pour voir.
 

 
Merci pour cet avis sur les VPN (en général, je suppose, par sur HMA en particulier ?).
 
Tout le monde est du même avis que toi sur ce forum ?
 
Quoi mettre en place alors, selon toi, pour sécuriser les infos transmises sur Internet ?
 
Te remerciant.

Ça me parait compliqué en tout cas.
Ce n'est pas prévu pour tout du moins.
 
 

Non je pense que je dois faire partie d'une toute petite minorité
 
Il y a eu tellement d'articles alarmistes au sujet des collectes gouvernementales qu'énormément de spécialistes auto-proclamés ou de journalistes en quête de buzz se sont fendus d'un article mettant en avant les avantages - très largement exagérés - des VPN comme solution à ce problème.
Sauf que ce n'est pas une véritable solution mais plutôt de nouveaux problèmes pour les raisons développées dans mon précédent message.
 
Beaucoup ont fait la confusion entre sécurité des données et anonymisation des données.
On est pas dans une dictature, si on a rien à se reprocher il n'y a aucun intérêt à masquer l'origine et la destination de ses transactions sur internet (métadonnées).
 
Par contre, à l'inverse, il est important de sécuriser de manière chiffrée ses transactions sur internet.
Il faut donc entre autre privilégier l'usage du SSL/TLS pour ne pas que les données soient interceptées par des personnes malveillantes.
Par données ici on ne parle plus de métadonnées mais bien du contenu des échanges: mots de passe, coordonnées bancaires, données personnelles, etc...
 
Donc dans ton cas je te conseillerai surtout de sécuriser tes envois de mail en implémentant du TLS au niveau de ton serveur de messagerie: en entrée comme en sortie.
Certains relais de messagerie continueront de n'accepter de recevoir / transmettre qu'en clair car c'était la norme jusqu'à il y a pas longtemps.
De même la plupart des implémentations TLS sont mal faites et n'empêchent pas l'interception des données.
Une bonne implémentation se repose sur l'usage de certificats valides et signés par une autorité de confiance. Elle repose également sur des mécanismes de contrôles des certificat présentés.
Malheureusement il y a souvent des lacunes pour les deux.

Le VPN n'est pas fait pour faire passer la messagerie.
Les gens cherchent de fiabilité avant tout, ils veulent pouvoir envoyer et recevoir tous les messages.
Ceux qui s'en fichent de la fiabilité sont plutôt les spammeurs qui recherchent plus à envoyer un grand nombre de mails sans être bloqué.
Il y aura personne ici qui aura configuré un serveur mail derrière un VPN.

Re,
 
J'ai édité le titre du post car le sujet dévie quelque peu.
 

 
 
Ok, merci à tous les 2. J'ai bien compris que pour la messagerie, je me trompe d'outil.  
Dans l'idée, je voulais simplifier et sécuriser la gestion de mes flux avec mon nouveau routeur et un VPN. Je comprends bien que pour la messagerie, ça va pas le faire.
 

 
Tu as raison, je confonds (mais comme beaucoup je pense) sécurité et anonymat.
 
Je te rassure, je ne fais rien d'illégal. Cela étant, je ne tiens pas non plus à étaler ce que je fais au grand jour. Cela ne regarde que moi, mes proches et depuis un certain nombre d'années mon fournisseur d'accès Internet. C'est vrai qu'en prenant un service VPN commercial, je ne fais que déplacer le problème du FAI au fournisseur VPN qui n'est pas en France, je te l'accorde. Je n'ai pas à l'heure actuelle (et tu t'en doute bien au vu de mes questions) les compétences pour mettre en place mon propre serveur VPN hébergé dans un pays exotique (ou non d'ailleurs). Je vais donc effectivement sur tes bons conseils arrêter le service VPN commercial. Tu as raison, c'est plus de problèmes qu'une sécurité.
 
Mes 2 principaux usages sont (comme beaucoup aussi je pense) les mails et la consultation de pages web.
 
Pour les mails, toutes mes boites sont (de mémoire mais je vais vérifier) en SSL/TLS en émission et en réception.
 
Pour la consultation des pages web, tu préconise quoi pour utiliser SSL/TLS ? ne consulter que des sites https ? Avec https everywhere ? Ou il y a une autre astuce ?  
 
Vous remerciant tous les 2 de votre aide.

Si tu veux de l'anonymat et de la sécurité, il y a :
La sécurité (antivirus, mise à jour de logiciel & Windows)
Le pistage (ne pas aller sur facebook, google & co, utiliser ghostery ou autres)
Les agences gouvernementales (privilégier les connexions cryptées).
 
Tu ne peux pas être invisible, tu laisses toujours des traces.
Faire ton propre serveur VPN/proxy à l'étranger serait effectivement une solution un cran plus haut pour l'anonymat.
C'est faisable mais ça demande un peu de boulot.

Bonjour,
 
 
Ca, c'est déjà fait.
 
 
 
Tu veux dire ne consulter que des sites https ? C'est vrai que je n'y fait probablement suffisamment attention. Toutefois, quand j'ai un message de firefox de connexion non certifiée, je regarde quand même où je suis.
 
 
 
Effectivement, je me doute bien et je n'en suis pas encore là. J'y viendrai peut-être. Après se pose également la question de confiance en l'hébergeur. Tu as une piste à ce sujet ?
 
Te remerciant de ton aide.

Les sites cryptés necessites un certificat qui est payant.
Certains sites utilisent des certificats auto signés, c'est à dire que c'est eux qu'ils l'ont fait et qu'il n'est pas reconnu par les autorités.
L'avertissement te signale qu'ils ne remplissent pas toutes les conditions de sécurité, mais la connexion n'en reste pas moins cryptée.
 
 
Pour l’hébergeur, il faut mieux en prendre un qui ne soit pas sous l'autorité du patriot act.
Ensuite une fois que tu as ton serveur, il est difficile de rentrer dessus pour quelqu'un de chez l'hébergeur, autant que pour une personne extérieure (tant qu'il est bien configuré).
 

Merci de ces précisions.

Je me permets de corriger certaines affirmations de nnwldx car il y a rien de pire que les informations incomplètes et erronées et ça conduit justement aux points que j'ai évoqué précédemment (j'ai rien contre toi hein ne m'en veux pas )
 
 
1) Il y a des autorités qui fournissent gratuitement des certificats et ces autorités sont reconnues par les navigateurs.
Payer pour un certificat c'est avant tout payer pour un niveau de "confiance" associé à une autorité de certification qui va signer le certificat.
Il y a eu plusieurs cas d'autorités ayant collaboré avec des entités gouvernementales (en Chine uniquement) ou s'étant faites piratées.
Dans ces cas-là il y a une perte de confiance envers cette autorité et dans le pire des cas elle peut carrément être retirée des navigateurs.
Je vais pas rentrer davantage dans les détails mais il y a aussi plusieurs niveaux de certificats et également d'autres avantages associés mais ça ne s'adresse pas aux utilisateurs ou particuliers.
 
2) Les certificats auto-signés t'exposent pratiquement autant que si tu n'avais pas de certificat, c'est donc à éviter.
Un pirate, un FAI, un hébergeur ou plus généralement n'importe qui qui arriverait à se positionner entre le client et le serveur pourrait intercepter le trafic à la volée et voir l'intégralité du contenu comme si c'était en clair et sans que le client ne s'en rende compte car il n'a aucun moyen de distinguer 2 certificats auto-signés entre eux.
(cf cinématique de l'établissement d'une communication SSL sécurisée pour plus d'infos)
 
 
 
1) Plus généralement n'importe quelle entité: hébergeur, opérateur télecom, FAI, etc... pouvant se placer entre le client et le serveur peut agir sur le trafic qui transite. La seule solution pour empêcher ça c'est d'établir une connexion SSL sécurisée avec un certificat reconnu par le client et à ce compte-là aucune des entités intermédiaires ne pourra agir (modifier, lire, ...) le trafic.
Ça n'a donc que peu d'importance de savoir l'affiliation des entités de transit sauf si tu veux éviter la connecte de métadonnées à la rigueur, mais le contenu sera lui protégé.
 
2) Il y a eu plusieurs cas de trojan / back-door hardware permettant de contourner les protections d'un serveur et d'y donner accès.
De même un serveur dont les disques ne sont pas chiffrés peut facilement être altéré comme s'il n'y avait pas de filtrage d'accès, et ce tout OS confondu.

Merci de ces précisions. Très intéressant ces échanges sur la sécurité. Je vois qu'il faut encore que je me documente pour bien comprendre SSL/TLS, certificats, ...
 
Sur la page de Wikipédia, j'ai trouvé http://assiste.com/HTTPS_Everywhere.html. Vous en pensez quoi ? C'est une bonne base pour un début ou il y a mieux ?
 
Vous remerciant de votre aide.

Ce programme ne te sera pas utile.
Quand tu te connecte sur un site, il peut fonctionner en http ou https,
parfois l'un, parfois l'autre ou les 2.
Si ton site ne fonctionne qu'en http, tu ne pourras pas te connecter en https dessus, car il n'est pas prévu pour.
Le chiffrement de données n'est pas utile pour tous les sites.
 
Il y a un mouvement "let's encrypt" qui veut chiffrer toutes les connexions des sites en leur fournissant un certificat.
Peut-être que tous passera en chiffré d'ici quelques années.
Pour l'instant je ne connais qu'une seul autorité qui fournit des certificats gratuitement, mais je ne suis pas sûr qu'ils soient reconnuent partout.

Ok mais je ne parlais pas uniquement du programme mais aussi de la documentation du site. C'est un bon début pour essayer de comprendre, non ?
 
Quelle est cette autorité qui fournit des certificats gratuitement ? StartSSL ? CACert ?
 
Te remerciant.

Oui, toute sources de documentation est bonne.
La société qui fournit gratuitement les certificats est startSSL.
 
Quand tu te connecte en https tu as une connexion http + SSL
On devrait dire TLS au lieu SSL car la technologie SSL a des failles de sécurités et TLS est le remplaçant.
Cependant les sites te parleront toujours de certificat SSL
 
Quand tu te connecte sur un site en https, ton navigateur va vérifier le certificat du site.
il regarde d'abord si le nom correspond, si la date est valide, si il es reconnu par une autorité de certification.
Si jamais ce n'est pas le cas, il t'affiche un avertissement.
Après il regarde si ton certificat est toujours valide.
Ensuite avec un système de chiffrement assymétrique avec un le certificat et un système de clef publique/ privée, il te permet de communiquer de façon chiffrée.
 
Mais tout cela se fait du coté serveur, tu ne peux pas obliger un serveur à fournir une connexion cryptée.
Le programme que cite force la connexion chiffrée si jamais il voit qu'elle est disponible.