Aller au contenu

Messages recommandés

Posté(e)

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 ! 

image.png

image.png

image.png

Posté(e)

@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

Posté(e)

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

 

Posté(e)

@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😉

Posté(e)

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 ?

Posté(e)
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

Posté(e) (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 :

pCwMdjy.png

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é par oracle7
Posté(e)

@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😉

Posté(e)

@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😉

Posté(e)

@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😉

Posté(e) (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é par CyberFr
Posté(e)

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 ?

Posté(e) (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é par CyberFr
Posté(e)

@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 :

WBQwdiK.pnguJP7a4W.png

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>

 

Posté(e) (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é par CyberFr
Rectification, j'aurais dû dire "Tu es sûr de ton coup"
Posté(e)

@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😉

Posté(e)
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.

Posté(e)

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.

Posté(e)

@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😉

Posté(e)

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.

Posté(e)

@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😉

Posté(e) (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é 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.
Posté(e)

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.

Posté(e)

@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😉

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.

Invité
Répondre à ce sujet…

×   Collé en tant que texte enrichi.   Coller en tant que texte brut à la place

  Seulement 75 émoticônes maximum sont autorisées.

×   Votre lien a été automatiquement intégré.   Afficher plutôt comme un lien

×   Votre contenu précédent a été rétabli.   Vider l’éditeur

×   Vous ne pouvez pas directement coller des images. Envoyez-les depuis votre ordinateur ou insérez-les depuis une URL.

×
×
  • Créer...

Information importante

Nous avons placé des cookies sur votre appareil pour aider à améliorer ce site. Vous pouvez choisir d’ajuster vos paramètres de cookie, sinon nous supposerons que vous êtes d’accord pour continuer.