Vaad Posté(e) le 14 octobre 2021 Posté(e) le 14 octobre 2021 Bonjour la communauté Je fais appelle à vous car j’ai un problème qui dure depuis plusieurs mois et que je n’arrive pas à le résoudre. J’ai un synology 920+ depuis un an sur lequel j’avais mis en place un VPN L2TP/IPSec qui marchait pour accéder à mon nas depuis l’extérieur. Seulement voilà j’ai changé d’opérateur et j’ai dû faire des changements de configuration (passage ip fixe à dynamique) et depuis je n’arrive plus à avoir un accès extérieur. J’ai voulu passer par OpenVPN cette fois et j’ai suivi plein de tuto dont celui de fenry mais j’ai toujours le même problème, ma connexion VPN est bien détecté dans vpn server mais je n’arrive pas à accéder au nas depuis l’extérieur. Pourtant j’ai bien : -Créer mon DDNS synology.me. -Autoriser la règle dans le pare-feu. -Fait la redirection du port dans les règles NAT. -Exporté la configuration du vpn et éditer le fichier. J’ai testé en full et split tunneling mais ça ne change rien. Par contre je ne sais pas si j’ai autre chose à faire à par renseigner le nom de domaine comme par exemple toucher à l’option dhcp-option DNS DNS_IP_ADDRESS. Mais comme je ne sais pas exactement à quoi ça correspond je n’ai rien modifié. -Et pour finir j’ai bien mis le fichier édité dans mon client vpn. Et quand je fais le teste en passant par la connexion 4G partagée de mon téléphone j’ai bien la connexion vpn qui apparaît dans vpn server mais quel que soit ce que je tape dans ma barre url je n’arrive pas à avoir l’accès. (D’ailleurs c’est un peu flou aussi ce que je dois taper. Si j'ai bien compris ça dépend du tunneling. En full je dois taper l’ip local du serveur et si je suis en split c’est l’adresse sous la forme 10.8.X.X et pour cette adresse je ne sais pas non plus si je dois mettre 10.8.0.0 ou 10.8.0.1 et encore autre chose. J'ai essayé toutes solutions, même taper mon nom de domaine directement rien n’y fait). Je me suis même demandé si ce n’était pas le pare-feu de la box qui bloquait mais je n’ai pas trop envie d’y toucher. Voilà mon état des lieux 😄. J’espère que quelqu’un pourra m’aider parce que maintenant je tourne en rond et je ne sais plus vraiment quoi faire. S’il manque des infos ou besoin de préciser quelque chose n’hésitez pas à me demander. Bonne journée à tous ! 0 Citer
Jeff777 Posté(e) le 14 octobre 2021 Posté(e) le 14 octobre 2021 @bliz bonne remarque mais c'est fait avec 10.0.0.0/255.0.0.0 qui autorise bien plus. Il y a 1 heure, Vaad a dit : Par contre je ne sais pas si j’ai autre chose à faire il faut décommenter la ligne redirect-gateway def1 1 Citer
ml78 Posté(e) le 14 octobre 2021 Posté(e) le 14 octobre 2021 Ça serait bien d'avoir les logs du coté du client (et sous Windows, ça serait parfait). Un petit condensé de mon fichier openvpn.ovpn Windows et iPhone et iPad : dev tun tls-client remote .... 1195 dhcp-option DNS 10.20.30.254 pull proto udp4 script-security 2 reneg-sec 0 cipher AES-256-CBC data-ciphers AES-256-CBC:AES-256-GCM:AES-128-GCM allow-compression no auth SHA512 auth-user-pass login.conf <ca> .... </ca> 0 Citer
oracle7 Posté(e) le 14 octobre 2021 Posté(e) le 14 octobre 2021 @ml78 Bonjour, Étonnant ton fichier de conf.opvn, je trouve qu'il est un peu éloigné du standard par défaut produit par un export du NAS, mais ce n'est que mon avis ... Tu utilises le port 1195 qui n'est pas le port standard d'OpenVPN, tu as sûrement une bonne raison à cela mais pourquoi ne pas utiliser simplement le port 1194 fixé par l'officielle IANA ? La commande "proto upd4" n'existe pas sauf erreur de ma part c'est plutôt "proto udp". Il te manquerait aussi les commandes : key-direction 1, comp-lzo et explicit-exit-notify Je constate aussi que seul ton trafic vers ton NAS passe par le VPN ( ceci û à l'absence de la commande redirect-gateway def1 et de la commande redirect-gateway ipv6 (spécifique à iOS et iPhone) ), tu ne crains pas que la partie de ton trafic vers Internet soit "espionnée" ? Pourquoi pas ... Maintenant ce que j'en dit ... Cordialement oracle7😉 0 Citer
Vaad Posté(e) le 14 octobre 2021 Auteur Posté(e) le 14 octobre 2021 Merci pour les réponses. J'ai retenté l'expérience en décochant redirect-gateway def1et en modifiant le pare-feu avec 10.8.0.0 pour voir et même résultat, se connecte au vpn mais pas d'accès. Pour être sûr, dans le fichier conf d'openvpn je dois renseigner mon nom de domaine lié au nas c'est bien ça ? Et ensuite sur le net j'ai met juste 10.8.0.0 ? Où est-ce que je peux trouver les logs du client sous windows ? 0 Citer
ml78 Posté(e) le 14 octobre 2021 Posté(e) le 14 octobre 2021 il y a 51 minutes, oracle7 a dit : @ml78 Bonjour, Étonnant ton fichier de conf.opvn, je trouve qu'il est un peu éloigné du standard par défaut produit par un export du NAS, mais ce n'est que mon avis ... Tu utilises le port 1195 qui n'est pas le port standard d'OpenVPN, tu as sûrement une bonne raison à cela mais pourquoi ne pas utiliser simplement le port 1194 fixé par l'officielle IANA ? La commande "proto upd4" n'existe pas sauf erreur de ma part c'est plutôt "proto udp". Il te manquerait aussi les commandes : key-direction 1, comp-lzo et explicit-exit-notify Je constate aussi que seul ton trafic vers ton NAS passe par le VPN ( ceci û à l'absence de la commande redirect-gateway def1 et de la commande redirect-gateway ipv6 (spécifique à iOS et iPhone) ), tu ne crains pas que la partie de ton trafic vers Internet soit "espionnée" ? Pourquoi pas ... Maintenant ce que j'en dit ... Cordialement oracle7😉 1195, tout simplement, parce qu'à un moment il y eu 2 accès vpn, dont en 1194 que j'ai fermé une fois les test passés. Ça me sert surtout à accéder à des VM qui sont elles-même en VPN... L'openvpn du coté Windows n'aime pas trop comp-lzo 0 Citer
oracle7 Posté(e) le 14 octobre 2021 Posté(e) le 14 octobre 2021 (modifié) @Vaad@bliz Bonjour, Voilà ce qui ce passe selon que la ligne "#redirect-gateway def1" est commentée (avec #) ou non : Commentée --> VPN Split-Tunnel : le trafic n'est envoyé via votre réseau que s'il tente d'accéder à une ressource interne. Votre adresse IP lorsque vous naviguez vers un site en dehors de votre réseau sera l'adresse IP du réseau sur lequel vous vous trouvez actuellement. Non commentée --> VPN Full-Tunnel : tout le trafic est envoyé via votre réseau domestique. Votre adresse IP pour les requêtes internes et externes sera votre réseau domestique. En clair cela donne ceci : Il y a 2 heures, Vaad a dit : Où est-ce que je peux trouver les logs du client sous windows ? Tu clic-droit sur l'icone de OpenVPN GUI dans la barre des tâches et tu sélectionnes "Voir le log" sinon le fichier en lui même est : soit dans C:\Users\<tonUserWin>\OpenVPN\log soit dans le répertoire que tu as désigné par : clic-droit icône OpenVPN GUI / Configuration / Onglet Avancé. EDIT : Avant toutes choses pour le VPN, il conviendrait de t'assurer que ton NAS est bien accessible de l'extérieur avec ton domaine. On est bien d'accord que ton DDNS est défini sur ce domaine : "ddns.synology.me" et qu'il pointe bien vers ton @IP Externe (i.e. @IP Box). Je pars sur cette hypothèse pour la suite. On vérifies que ton DDNS pointe bien chez toi, en passant la commande "ping ddns.synology.me" depuis ton PC . La réponse doit être ton @IP Externe. On vérifie aussi dans un terminal SSH via PuTTY ou WinSCP, sous user root que nslookup ddns.synology.me 8.8.8.8, ça doit aussi te faire tomber sur ton @IP Externe. Depuis l'extérieur (tél 4G par ex), dans un navigateur Web : taper l'URL http://ddns.synology.me:5000 --> tu dois atteindre le NAS. Tout doit être OK avant d'aller plus loin avec le VPN. Cordialement oracle7😉 Modifié le 14 octobre 2021 par oracle7 1 Citer
oracle7 Posté(e) le 14 octobre 2021 Posté(e) le 14 octobre 2021 @bliz Bonjour, Ok je comprend que tu as décommentée la ligne redirect-gateway def1 pour passer en full-tunnel, mais après le reste de ta phrase ne me paraît pas clair du tout, tu pourrais reformuler STP ? C'est juste pour bien comprendre ... Cordialement oracle7😉 0 Citer
oracle7 Posté(e) le 14 octobre 2021 Posté(e) le 14 octobre 2021 @bliz Bonjour, Personnellement je m'en tiens à la documentation d'OpenVPN qui, pour la dite commande ne parle que de son effet Full ou Split tunnel selon quelle est activée ou non. Maintenant que cela ait pour conséquence une variation de débit constaté selon son activation ou non, me parait tout à fait normal et c'est même logique. Après comme tu le dit, qu'il faille l'activer selon le type de sécurité (lequel d'ailleurs ?) à balancer avec le débit que peux accepter le NAS, j'ai plus de mal à comprendre. Mais bon ... Cordialement oracle7😉 0 Citer
oracle7 Posté(e) le 14 octobre 2021 Posté(e) le 14 octobre 2021 @bliz Bonjour, Oui le split tunneling serait a priori moins sécure dans la mesure où tout ton trafic externe (qui n'est pas à destination de ton réseau local) peut être espionné, notamment tes requêtes DNS qui en disent long sur ton activité Internet. C'est donc bien pour cela il est fortement recommandé de passer par le Full tunneling pour sécuriser l'ensemble des flux. C'est mon humble avis qui n'engage que moi ... Cordialement oracle7😉 0 Citer
CyberFr Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 (modifié) Il y a 16 heures, ml78 a dit : Un petit condensé de mon fichier openvpn.ovpn Windows et iPhone et iPad : dev tun tls-client remote .... 1195 dhcp-option DNS 10.20.30.254 pull proto udp4 script-security 2 reneg-sec 0 cipher AES-256-CBC data-ciphers AES-256-CBC:AES-256-GCM:AES-128-GCM allow-compression no auth SHA512 auth-user-pass login.conf Voilà ce que je trouve dans le log d'OpenVPN : [Oct 14, 2021, 18:31:40] UNUSED OPTIONS 1 [tls-client] 3 [verify-client-cert] [none] 5 [auth-nocache] 9 [pull] 11 [script-security] [2] 14 [data-ciphers] [AES-256-CBC] J'ai supprimé toutes ces options dans le fichier de config d'autant plus que certaines sont définies directement dans les paramètres de l'application OpenVPN Connect. Et ça fonctionne très bien sans. Modifié le 15 octobre 2021 par CyberFr 0 Citer
Jeff777 Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 Bonjour, J'avais perdu un peu le fil. Intéressant ces info à propos du split/full tunnel. Merci pour ces explications. Je crois que je vais rester en full tunnel. Par contre pas de nouvelles de @Vaad ? 0 Citer
CyberFr Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 (modifié) Il y a 16 heures, oracle7 a dit : Il te manquerait aussi les commandes : key-direction 1, comp-lzo et explicit-exit-notify Bonjour @oracle7, La première et la troisième option servent à quoi ? Modifié le 15 octobre 2021 par CyberFr 0 Citer
oracle7 Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 @CyberFr Bonjour, Je te renvoie aux man pages d'OpenVPN pour cela --> ici tu y trouveras l'explication de chaque paramètre OpenVPN. Il y a 4 heures, CyberFr a dit : J'ai supprimé toutes ces options dans le fichier de config d'autant plus que certaines sont définies directement dans les paramètres de l'application OpenVPN Connect. Et ça fonctionne très bien sans. Ce n'est que mon avis mais je te trouve un peu cavalier sur ce coup là car quand le log m'affiche des UNUSED OPTIONS c'est que cela ne se passait pas bien, mais je peut me tromper.... Voilà un log quand tout est OK : Sinon, voici par exemple mon fichier de conf .ovpn : dev tun tls-client remote xxx.ndd.tld 1194 # The "float" tells OpenVPN to accept authenticated packets from any address, # not only the address which was specified in the --remote option. # This is useful when you are connecting to a peer which holds a dynamic address # such as a dial-in user or DHCP client. # (Please refer to the manual of OpenVPN for more information.) #float # If redirect-gateway is enabled, the client will redirect it's # default network gateway through the VPN. # It means the VPN connection will firstly connect to the VPN Server # and then to the internet. # (Please refer to the manual of OpenVPN for more information.) redirect-gateway def1 # A ajouter pour les iPhone #redirect-gateway ipv6 # dhcp-option DNS: To set primary domain name server address. # Repeat this option to set secondary DNS server addresses. #dhcp-option DNS DNS_IP_ADDRESS #dhcp-option DNS 192.168.2.1 pull # If you want to connect by Server's IPv6 address, you should use # "proto udp6" in UDP mode or "proto tcp6-client" in TCP mode proto udp script-security 2 # ping www.orange.fr -f -l 1500 => Par dichotomie on retrouve la MTU maximun pour la quelle le ping renvoie une réponse OK. # Si on a une réponse paquet FRAGMENTED on réduit de 10 jusqu'à avoir une réponse OK. On rajoute alors 1/2 du (Delta MTU NOK-MTU OK). # Si NOK on réduit encore de 1/2 du du (Delta MTU NOK-MTU OK) # Si OK on augmente encore de 1/2 du du (Delta MTU NOK-MTU OK) # Jusqu'à obtenir la valeur maximum de MTU OK. Alors on affecte cette valeur à la commande mssfix mssfix 1472 reneg-sec 0 auth SHA512 cipher AES-256-CBC auth-user-pass remote-cert-tls server auth-nocache key-direction 1 comp-lzo explicit-exit-notify <ca> -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- -----END CERTIFICATE----- </ca> <tls-auth> # # 2048 bit OpenVPN static key # -----BEGIN OpenVPN Static key V1----- -----END OpenVPN Static key V1----- </tls-auth> 0 Citer
CyberFr Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 (modifié) Merci @oracle7 pour les man page. il y a 29 minutes, oracle7 a dit : Ce n'est que mon avis mais je te trouve un peu cavalier sur ce coup là car quand le log m'affiche des UNUSED OPTIONS c'est que cela ne se passait pas bien, mais je peut me tromper.... Bon, il faut que j'approfondisse. Ton fichier de config (que j'ai transféré sur le bureau) sera une bonne base de départ. Je vais le comparer avec le mien. Je constate simplement qu'après avoir supprimé les UNUSED OPTIONS, je n'ai aucun avertissement dans le log d'OpenVPN et que je me connecte sans problème. Mais si tu dis "Je peux me tromper", cela signifie que tu es à peu près sur de ton coup 🙂 Modifié le 15 octobre 2021 par CyberFr Rectification, j'aurais dû dire "Tu es sûr de ton coup" 0 Citer
oracle7 Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 @CyberFr Bonjour, il y a 13 minutes, CyberFr a dit : Mais si tu dis "Je peux me tromper", cela signifie que tu es à peu près sur de ton coup Bah justement non, dans la mesure où cela a été un constat durant ma phase de mise au point de la connexion OpenVPN. J'attire l'attention juste sur ce point. C'est tout. Comme tu le dis, il reste du "à peu près" et rien n'est certain. Maintenant, cela servirait à quoi de mettre des instructions d'exécution spécifiques si après le logiciel n'en fait qu'à sa tête et les ignore ? S'il le fait c'est qu'il y a une bonne raison à cela. Logique ? Par ailleurs, pourquoi voudrais-tu que le log t'avertisse d'éventuelles erreurs concernant des options que tu n'as pas spécifiées ? S'il ne dit rien, c'est que tout est OK même s'il fait aussi du mode trace d'événements particuliers selon le mode verbeux défini. Je prend comme exemple la commande "pull" : la doc dit "This option must be used on a client which is connecting to a multi-client server". J'en déduit que si le log rapporte qu'elle n'a pas été utilisée, c'est qu'il y a un problème, mais là encore ce n'est que mon interprétation et donc c'est pourquoi je dis que je peux me tromper. Tu me suis ? Cordialement oracle7😉 0 Citer
CyberFr Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 il y a 27 minutes, oracle7 a dit : Tu me suis ? Bonjour @oracle7, Je vais employer le verbe suivre dans deux sens différents. Pour répondre à ta question, oui, je te suis. Par ailleurs, je sais par expérience que l'on a toujours intérêt à te suivre dans tes propositions. 1 Citer
CyberFr Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 Bonjour @oracle7, Je me retrouve avec ton fichier de configuration d'un coté, le mien de l'autre et enfin les man pages d'OpenVPN, tu parles d'une sinécure. Je retourne à l'école 🙂 Tu indiques remote xxx.ndd.tld 1194. Il s'agit de quel type d'adresse parce que j'ai indiqué remote 87.88.XXX.XXX 1194 qui est l'adresse publique de la box. #dhcp-option DNS 192.168.2.1 C'est normal que ce soit en commentaire ? # ping www.orange.fr -f -l 1500 => Par dichotomie on retrouve la MTU maximun pour la quelle le ping # renvoie une réponse OK. # Si on a une réponse paquet FRAGMENTED on réduit de 10 jusqu'à avoir une réponse OK. On rajoute alors # 1/2 du (Delta MTU NOK-MTU OK). # Si NOK on réduit encore de 1/2 du du (Delta MTU NOK-MTU OK) # Si OK on augmente encore de 1/2 du du (Delta MTU NOK-MTU OK) # Jusqu'à obtenir la valeur maximum de MTU OK. Alors on affecte cette valeur à la commande mssfix mssfix 1472 Alors là je me prends la tête. Il faut absolument faire le test lors d'une connection VPN ou on peut aussi le faire lors d'une connexion Internet normale ? Tu n'as pas utilisé l'option verify-client-cert. Ça se passe ailleurs ? Je me suis permis de remplacer "explicit-exit-notify" par "explicit-exit-notify 1". Je me méfie des valeurs par défaut. <tls-auth> # # 2048 bit OpenVPN static key # -----BEGIN OpenVPN Static key V1----- -----END OpenVPN Static key V1----- </tls-auth> Je ne suis pas parvenu à installer un certificat malheureusement. 0 Citer
oracle7 Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 @CyberFr Bonjour, il y a 26 minutes, CyberFr a dit : Tu indiques remote xxx.ndd.tld 1194. Il s'agit de quel type d'adresse parce que j'ai indiqué remote 87.88.XXX.XXX 1194 qui est l'adresse publique de la box. "xxx.ndd.tld " est le sous-domaine qui pointe sur l'@IP locale de mon routeur (support de VPN Plus Server et de DNS Server) via le Reverse Proxy et sachant que c'est l'@IP externe de ma Livebox qui est vue par la connexion VPN depuis l'extérieur. J'espère être clair. il y a 34 minutes, CyberFr a dit : #dhcp-option DNS 192.168.2.1 C'est normal que ce soit en commentaire ? OUI, car lorsque tu ne précises pas d'@IP avec l'option dhcp-option DNS @IP, c'est l'@IP du serveur DNS du VPN Server qui est utilisée par défaut. Dans mon cas c'est l'@IP locale de mon routeur qui lui supporte DNS Server. Cela se voit bien dans le log OpenVPN (voir ma copie d'écran précédente) à la ligne n°1. il y a 38 minutes, CyberFr a dit : Alors là je me prends la tête. Il faut absolument faire le test lors d'une connection VPN ou on peut aussi le faire lors d'une connexion Internet normale ? Tu le fais dans une connexion normale depuis ton réseau local sur un PC (fenêtre CMD Windows en mode admin) / Mac (je suppose dans une fenêtre de Terminal, là c'est toi qui sais ...). En clair par exemple : tu commence à 1500 avec un ping www.orange.fr -f -l 1500 Puis 1490, 1480, 1470, etc ... jusqu'à ce que la réponse au ping soit OK. Ensuite 1475 : si NOK alors tu refais avec 1473 : si NOK, tu refais avec 1471 si OK tu refais avec 1472 : si OK alors 1472 est la valeur maxi de MTU à retenir et à mettre dans la commande mssfix du fichier de conf .ovpn. Tu lances ensuite ta connexion OpenVPN, et là tu constateras que ta connexion (enfin l'accès aux URL) est bien plus rapide (même nettement à mon avis) que ce que tu avais avant de configurer la commande mssfix. C'est normal car ainsi on a optimisé au mieux la taille des paquets transmis/échangés. Des paquets trop grands ou trop petits impactent la vitesse des échanges. il y a 52 minutes, CyberFr a dit : Tu n'as pas utilisé l'option verify-client-cert. Ça se passe ailleurs ? Non, peut-être que j'aurais dû mais comme mon certificat est chargé sur mon client, il est utilisé donc le revérifier avec cette commande, je ne sais si c'est vraiment utile. Mais peut-être que je me trompe, je suis preneur d'autres avis sur ce point. Cordialement oracle7😉 1 Citer
CyberFr Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 Bonjour @oracle7, J'espère que tu ne m'en voudras pas si je me suis largement inspiré de ton fichier de config mais comme tu l'as publié, il suffisait de faire un copier/coller. il y a 18 minutes, oracle7 a dit : "xxx.ndd.tld " est le sous-domaine qui pointe sur l'@IP locale de mon routeur (support de VPN Plus Server et de DNS Server) via le Reverse Proxy et sachant que c'est l'@IP externe de ma Livebox qui est vue par la connexion VPN depuis l'extérieur. J'espère être clair. Franchement il y a des choses qui m'échappent. Peut-être parce que je n'ai pas encore de routeur. il y a 19 minutes, oracle7 a dit : OUI, car lorsque tu ne précises pas d'@IP avec l'option dhcp-option DNS @IP, c'est l'@IP du serveur DNS du VPN Server qui est utilisée par défaut. Dans mon cas c'est l'@IP locale de mon routeur qui lui supporte DNS Server. Cela se voit bien dans le log OpenVPN (voir ma copie d'écran précédente) à la ligne n°1. Sur mon NAS, c'est la passerelle par défaut de la box qui est configurée, qui elle-même renvoie sur l'IP locale de DNS Server. J'ai donc indiqué directement cette adresse locale. il y a 22 minutes, oracle7 a dit : En clair par exemple : tu commence à 1500 avec un ping www.orange.fr -f -l 1500 Puis 1490, 1480, 1470, etc ... jusqu'à ce que la réponse au ping soit OK. Merci pour ces explications. 0 Citer
oracle7 Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 @CyberFr Bonjour, il y a 4 minutes, CyberFr a dit : Sur mon NAS, c'est la passerelle par défaut de la box qui est configurée, qui elle-même renvoie sur l'IP locale de DNS Server. J'ai donc indiqué directement cette adresse locale. Dans ton cas, sauf erreur de ma part, dans remote @IP 1194, pour @IP tu doit avoir ton @IP Externe (box) et pas une @IP locale. Ensuite en observant le log OpenVPN, tu devrais voir comme @IP du serveur DNS, l'@IP locale de ton NAS puisque c'est lui qui supporte DNS Server. J'ai bon ? Cordialement oracle7😉 0 Citer
CyberFr Posté(e) le 15 octobre 2021 Posté(e) le 15 octobre 2021 (modifié) il y a 15 minutes, oracle7 a dit : Dans ton cas, sauf erreur de ma part, dans remote @IP 1194, pour @IP tu doit avoir ton @IP Externe (box) et pas une @IP locale. Quand je relis mes réglages, c'est effectivement l'IP publique de la box qui apparaît. J'ai confondu avec dhcp-option DNS 192.168.1.X. Modifié le 15 octobre 2021 par CyberFr PS : Quand je fais un ping www.orange.fr -f -l 1500, je me fais jeter de partout que ce soit le site d'Orange ou un autre. Operation refused. 0 Citer
CyberFr Posté(e) le 16 octobre 2021 Posté(e) le 16 octobre 2021 UP Quand je fais un "ping www.orange.fr -f -l 1500", je me fais jeter de partout que ce soit sur le site d'Orange ou d'autres. Operation not permitted. Pas facile dans ces conditions de tester la MTU. 0 Citer
oracle7 Posté(e) le 16 octobre 2021 Posté(e) le 16 octobre 2021 @CyberFr Bonjour, Étonnant cela 🧐 Ce ne n'est qu'un simple "ping" , là je pige pas ce qui pourrait bloquer ... en lus on peut faire cela sur d'autres sites google, yahoo, etc ... C:\WINDOWS\system32>ping www.orange.fr -f -l 1472 Envoi d’une requête 'ping' sur www.orange.fr [193.252.133.97] avec 1472 octets de données : Réponse de 193.252.133.97 : octets=1472 temps=8 ms TTL=246 Réponse de 193.252.133.97 : octets=1472 temps=8 ms TTL=246 Réponse de 193.252.133.97 : octets=1472 temps=8 ms TTL=246 Réponse de 193.252.133.97 : octets=1472 temps=9 ms TTL=246 Statistiques Ping pour 193.252.133.97: Paquets : envoyés = 4, reçus = 4, perdus = 0 (perte 0%), Durée approximative des boucles en millisecondes : Minimum = 8ms, Maximum = 9ms, Moyenne = 8ms C:\WINDOWS\system32>ping www.orange.fr -f -l 1500 Envoi d’une requête 'ping' sur www.orange.fr [193.252.133.97] avec 1500 octets de données : Le paquet doit être fragmenté mais paramétré DF. Le paquet doit être fragmenté mais paramétré DF. Le paquet doit être fragmenté mais paramétré DF. Le paquet doit être fragmenté mais paramétré DF. Statistiques Ping pour 193.252.133.97: Paquets : envoyés = 4, reçus = 0, perdus = 4 (perte 100%), Cordialement oracle7😉 0 Citer
CyberFr Posté(e) le 16 octobre 2021 Posté(e) le 16 octobre 2021 Bonjour @oracle7, Voilà ce que ça donne sur ma machine LaX1:~ lionel$ ping www.orange.fr -f -l 1472 ping: -f flag: Operation not permitted LaX1:~ lionel$ Je crois que je vais revendre mon Mac 🤢 0 Citer
Messages recommandés
Rejoindre la conversation
Vous pouvez publier maintenant et vous inscrire plus tard. Si vous avez un compte, connectez-vous maintenant pour publier avec votre compte.