[RESOLU] Obliger les navigateurs à se connecter en ipv4

mickbad · Le 26/10/2016, à 17:10

Bonjour,

Un souci épineux pour moi : obliger les navigateurs (via leur connexion) à se connecter sur un serveur en ipv4 et non en ipv6 si le fai le permet

Déjà, pas la peine de dire que ipv6 c'est l'avenir et qu'il faut laisser comme cela. C'est ce qu'on me demande pour faire fonctionner un logiciel statistique !
En gros dans mon log nginx, j'ai des utilisateurs en ipv4 et d'autres en ipv6 et je ne veux que des utilisateurs en ipv4

Le serveur est sous ubuntu 16.04 (et un autre en 14.04) chez OVH.

J'ai désactivé les réponses ipv6 de eth0 via sysctl

# sysctl -a | fgrep disable_ipv6
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.bond0.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.dummy0.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.eth1.disable_ipv6 = 1
net.ipv6.conf.ifb0.disable_ipv6 = 1
net.ipv6.conf.ifb1.disable_ipv6 = 1
net.ipv6.conf.ip6tnl0.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.sit0.disable_ipv6 = 1
net.ipv6.conf.teql0.disable_ipv6 = 1
net.ipv6.conf.tunl0.disable_ipv6 = 1

cela fonctionne car le ifconfig donne un eth0 sans ipv6. De plus depuis un autre serveur, je ne pinge plus le serveur en ipv6 mais uniquement en ipv4

Au niveau de nginx, j'ai configuré tous les vhosts en ipv4

listen       80;
# listen       [::]:80;

Au niveau des ports ouverts, j'ai ceci pour nginx :

tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      0          10462406    17516/nginx.conf

Pas de trace d'un démarrage de nginx en ipv6

Ainsi, j'ai banni l'ipv6 du serveur

Pourtant dans le log nginx, j'ai des accès d'internaute en ipv4 et en ipv6.

Please, comment indiquer que je n'accepte que des internautes en ipv4 ?

Est-ce possible ? Chez OVH ?

Merci beaucoup
Mick

Dernière modification par mickbad (Le 27/10/2016, à 13:48)

elburgos · Le 26/10/2016, à 20:51

Essaye en ne mettant pas

--with-ipv6

dans ta config et avec :

resolver ............ipv6=off

les postes ici et là en parlent

donut · Le 27/10/2016, à 08:29

J'ai du mal à voir comment c'est possible que ton serveur réponde en IPv6 vu l'artillerie lourde que tu as utilisé. Le retrait de la directive listen [::] dans nginx aurait même du suffire.
J'imagine qu'il y a un nom de domaine qui fait pointer tes utilisateurs sur le serveur, assure-toi qu'il n'a pas d'entrée AAAA (hôte ipv6) dans la zone.

Dernière modification par donut (Le 27/10/2016, à 08:31)

bruno · Le 27/10/2016, à 08:43

Bonjour,

Tout a fait d'accord avec donut.
C'est désactivé au niveau du serveur web et c'est désactivé au niveau du système !
Avec cette configuration il est impossible que des utilisateurs se connectent en IPv6 à moins que les modifications de configuration aient été faites sans avoir redémarré les services concernés : nginx et réseau.

Maintenant je ne comprends pas bien pourquoi tu veux empêcher les connexion en IPv6…

Dernière modification par bruno (Le 27/10/2016, à 08:46)

mickbad · Le 27/10/2016, à 09:07

Bonjour

Merci pour les retours intéressants

elburgos a écrit :

Essaye en ne mettant pas
--with-ipv6 
dans ta config et avec :
resolver ............ipv6=off
les postes ici et là en parlent

J'ai mis resolver 8.8.8.8 ipv6=off dans mon vhost (dans location et hors location), et j'ai cette erreur dans le démarrage de nginx

[emerg] 1647#0: host not found in resolver "proxy_set_header" in /path/to/vhost/domaine.d/main.conf:3

Dans la définition du vhost, j'ai déjà proxy_set_header mais j'ai vu que cela faisait le même symptôme qu'avec le code suivant

location / {
    resolver 8.8.8.8 ipv6=off
    proxy_set_header   Host $host;
    proxy_pass      $backend_protocol://$backend_host:$backend_port;
}

Du coup nginx ne démarre plus

donut a écrit :

J'imagine qu'il y a un nom de domaine qui fait pointer tes utilisateurs sur le serveur, assure-toi qu'il n'a pas d'entrée AAAA (hôte ipv6) dans la zone.

Oui effectivement c'est une piste
Regarde,

$ dig www.mondomaine.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.mondomaine.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 46334
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.mondomaine.com.    IN      A

;; ANSWER SECTION:
www.mondomaine.com. 300 IN      A       104.24.30.21
www.mondomaine.com. 300 IN      A       104.24.31.21

;; AUTHORITY SECTION:
mondomaine.com. 172799  IN      NS      cloe.ns.cloudflare.com.
mondomaine.com. 172799  IN      NS      guss.ns.cloudflare.com.

;; ADDITIONAL SECTION:
cloe.ns.cloudflare.com. 219     IN      A       173.245.58.86
cloe.ns.cloudflare.com. 219     IN      AAAA    2400:cb00:2049:1::adf5:3a56
guss.ns.cloudflare.com. 219     IN      A       173.245.59.172
guss.ns.cloudflare.com. 219     IN      AAAA    2400:cb00:2049:1::adf5:3bac

;; Query time: 563 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 27 09:53:04 CEST 2016
;; MSG SIZE  rcvd: 227

Le site passe par cloudflare effectivement et le problème vient peut être de lui ?

bruno a écrit :

Maintenant je ne comprends pas bien pourquoi tu veux empêcher les connexion en IPv6…

Je suis d'accord avec toi mais c'est une spécification d'un logiciel que je ne maîtrise pas et qui réclame de l'ipv4 uniquement comme source des internautes. Je te l'accorde, c'est étrange

D'une manière générale, oui l'ipv6 est désactivé et j'ai bien redémarré les services
Dans les logs access de nginx, j'ai des internautes en ipv6, gloups !

Mick

Dernière modification par mickbad (Le 27/10/2016, à 09:19)

donut · Le 27/10/2016, à 09:27

On ne viole pas son Nginx, c'est sale !

Fais la commande suivante :

netstat -tapn

Ainsi tu verra tous les services qui écoutent sur le réseau, et s'il y a bien de l'IPv6 ou non.

mickbad · Le 27/10/2016, à 09:27

Voici la zone DNS chez cloudflare

@	3600	IN	SOA	domaine.com.	root.domaine.com.	(
		2022922313	; serial
		7200		; refresh
		3600		; retry
		86400		; expire
		3600)		; minimum

;; NS Records (YOU MUST CHANGE THIS)
fid1.domaine.com.	300	IN	NS	ns1.autre_domaine.com.
fid1.domaine.com.	300	IN	NS	ns2.autre_domaine.com.
tr2.domaine.com.	300	IN	NS	ns1.autre_domaine.com.
tr1.domaine.com.	300	IN	NS	ns2.autre_domaine.com.
tr2.domaine.com.	300	IN	NS	ns2.autre_domaine.com.
spv1.domaine.com.	300	IN	NS	ns2.autre_domaine.com.
spv1.domaine.com.	300	IN	NS	ns1.autre_domaine.com.
tr1.domaine.com.	300	IN	NS	ns1.autre_domaine.com.
fid6.domaine.com.	300	IN	NS	ns1.autre_domaine.com.
fid5.domaine.com.	300	IN	NS	ns2.autre_domaine.com.
fid6.domaine.com.	300	IN	NS	ns2.autre_domaine.com.
fid4.domaine.com.	300	IN	NS	ns2.autre_domaine.com.
fid4.domaine.com.	300	IN	NS	ns1.autre_domaine.com.
fid5.domaine.com.	300	IN	NS	ns1.autre_domaine.com.
fid3.domaine.com.	300	IN	NS	ns1.autre_domaine.com.
fid2.domaine.com.	300	IN	NS	ns2.autre_domaine.com.
fid3.domaine.com.	300	IN	NS	ns2.autre_domaine.com.
fid2.domaine.com.	300	IN	NS	ns1.autre_domaine.com.

;; MX Records
domaine.com.	300	IN	MX	10	spool.mail.gandi.net.
domaine.com.	300	IN	MX	50	fb.mail.gandi.net.

;; CNAME Records
_xmpp-client._tcp.domaine.com.	300	IN	CNAME	webredir.vip.gandi.net.
_xmpp-server._tcp.domaine.com.	300	IN	CNAME	webredir.vip.gandi.net.
pop.domaine.com.	300	IN	CNAME	access.mail.gandi.net.
wpe.domaine.com.	300	IN	CNAME	www.domaine.com.
smtp.domaine.com.	300	IN	CNAME	relay.mail.gandi.net.
devm5.domaine.com.	300	IN	CNAME	gpaas2.dc1.gandi.net.
_jabber._tcp.domaine.com.	300	IN	CNAME	webredir.vip.gandi.net.
imap.domaine.com.	300	IN	CNAME	access.mail.gandi.net.
domaine.com.	300	IN	CNAME	www.domaine.com.
devm4.domaine.com.	300	IN	CNAME	gpaas2.dc1.gandi.net.
devm2.domaine.com.	300	IN	CNAME	gpaas2.dc1.gandi.net.

;; A Records (IPv4 addresses)
migration.domaine.com.	300	IN	A	1.1.1.1
www.domaine.com.	300	IN	A	1.1.1.1
preprod.domaine.com.	300	IN	A	2.2.2.2

Pas d'entrée AAAA

ça devient étrange

Mick

mickbad · Le 27/10/2016, à 09:30

donut a écrit :

On ne viole pas son Nginx, c'est sale !
Fais la commande suivante :
netstat -tapn
Ainsi tu verra tous les services qui écoutent sur le réseau, et s'il y a bien de l'IPv6 ou non.

$ netstat -tapn
...
tcp6       0      0 :::22                   :::*                    LISTEN      1045/sshd

Tu crois que cela peut avoir une incidence sachant que c'est la seule entrée en tcp6 ?

Merci

donut · Le 27/10/2016, à 09:31

Autre possibilité (à confirmer) : vu que tu utilises un cloudflare en frontal, les IPv6 que tu vois c'est peut-être simplement du aux en-têtes X-Forwarded-For qui te sont transmises.

Explications :

L'utilisateur entre l'url dans son navigateur, c'est cloudflare qui reçoit la requête et la transmet à ton serveur.
Le problème c'est que ton serveur va logguer l'ip du serveur cloudflare, et non celle du visiteur puisque la requête vient de là.
Donc pour palier à ça on utilise un header X-Forwarded-For. C'est à dire que cloudflare ajoute l'ip du client comme information dans la requête qui t'es transmise.
Et c'est comme ça que tu vois de l'IPv6 alors que cloudflare t'envoie bien de l'IPv4.

EDIT : fais un :

dig AAAA tondomaine

Pour être sûr

Dernière modification par donut (Le 27/10/2016, à 09:33)

donut · Le 27/10/2016, à 09:33

mickbad a écrit :

donut a écrit :
On ne viole pas son Nginx, c'est sale !
Fais la commande suivante :
netstat -tapn
Ainsi tu verra tous les services qui écoutent sur le réseau, et s'il y a bien de l'IPv6 ou non.
$ netstat -tapn
...
tcp6       0      0 :::22                   :::*                    LISTEN      1045/sshd       
Tu crois que cela peut avoir une incidence sachant que c'est la seule entrée en tcp6 ?
Merci

Nginx était en fonctionnement ?
Car ce que tu vois c'est le service SSH, qui écoute en IPv6 effectivement.

mickbad · Le 27/10/2016, à 09:35

donut a écrit :

EDIT : fais un :
dig AAAA tondomaine
Pour être sûr

Merci vraiment de vos aides

$ dig AAAA www.domaine.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> AAAA www.domaine.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40778
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.domaine.com.    IN      AAAA

;; ANSWER SECTION:
www.domaine.com. 300 IN      AAAA    2400:cb00:2048:1::6818:1e15
www.domaine.com. 300 IN      AAAA    2400:cb00:2048:1::6818:1f15

;; AUTHORITY SECTION:
domaine.com. 170365  IN      NS      guss.ns.cloudflare.com.
domaine.com. 170365  IN      NS      cloe.ns.cloudflare.com.

;; ADDITIONAL SECTION:
cloe.ns.cloudflare.com. 170674  IN      A       173.245.58.86
cloe.ns.cloudflare.com. 170674  IN      AAAA    2400:cb00:2049:1::adf5:3a56
guss.ns.cloudflare.com. 170674  IN      A       173.245.59.172
guss.ns.cloudflare.com. 170674  IN      AAAA    2400:cb00:2049:1::adf5:3bac

;; Query time: 296 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Oct 27 10:33:38 CEST 2016
;; MSG SIZE  rcvd: 251

J'avoue être un peu léger en dns

Nginx était en fonctionnement ?
Car ce que tu vois c'est le service SSH, qui écoute en IPv6 effectivement.

Oui nginx en état de fonctionnement en tcp seul

tcp        0      0 0.0.0.0:3306            0.0.0.0:*               LISTEN      27342/mysqld    
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN      4893/nginx.conf 
tcp        0      0 127.0.0.1:81            0.0.0.0:*               LISTEN      1410/httpd      
tcp        0      0 127.0.0.1:53            0.0.0.0:*               LISTEN      1046/named      
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1045/sshd       
tcp        0      0 127.0.0.1:25            0.0.0.0:*               LISTEN      1547/master     
tcp        0      0 127.0.0.1:953           0.0.0.0:*               LISTEN      1046/named      
...
tcp avec des connexions TIME_WAIT et ESTABLISHED
...
tcp6       0      0 :::22                   :::*                    LISTEN      1045/sshd

Mick

Dernière modification par mickbad (Le 27/10/2016, à 09:38)

donut · Le 27/10/2016, à 09:51

Vu ce que tu indiques :
- Nginx n'écoute pas en IPv6, tu ne reçois donc pas de trafic IPv6 dessus
- Ton domaine a des entrées IPv6

Donc on se rapproche de plus en plus de ce que j'expliquais avec les X-Forwarded-For.

mickbad · Le 27/10/2016, à 10:37

Oui l'explication sur le X-Forwarded-For se tient bien. Je n'y avais pas pensé. Je vais voir de ce côté là et sur serveur je n'ai plus rien à faire je pense

Merci en tout cas, j'ai une piste plausible

Mick

donut · Le 27/10/2016, à 10:42

mickbad a écrit :

Oui l'explication sur le X-Forwarded-For se tient bien. Je n'y avais pas pensé. Je vais voir de ce côté là et sur serveur je n'ai plus rien à faire je pense
Merci en tout cas, j'ai une piste plausible
Mick

Deux pistes :

- Si tu as la main sur le nom de domaine, retire les entrées AAAA
- Tu peux toujours lancer un tcpdump sur ton serveur, pour être certain qu'il n'y a bien que du trafic IPv4

mickbad · Le 27/10/2016, à 11:03

Pour la zone dns, je vais voir si je peux avoir la main sur les entrées AAAA (car naturellement sur cloudflare, il n'y a que des entrées A et CNAME)

Pour tcpdump, on fait des découvertes et cela semble bien confirmer ton hypothèse

# tcpdump -c 20000 -s 0 -i eth0 -A tcp port http | grep X-Forwarded-For

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
X-Forwarded-For: IPV4
X-Forwarded-For: IPV4
X-Forwarded-For: IPV4
X-Forwarded-For: IPV4
X-Forwarded-For: IPV4
X-Forwarded-For: IPV6
X-Forwarded-For: IPV6
X-Forwarded-For: IPV4
X-Forwarded-For: IPV6
X-Forwarded-For: IPV4
X-Forwarded-For: IPV4
^C537 packets captured
542 packets received by filter
0 packets dropped by kernel

J'ai du xforward en ipv6

sur une trace complète, j'ai ceci

11:59:02.231722 IP IPV4_CLOUDFLARE.32243 > host.mon_domaine.com.http: Flags [P.], seq 1:431, ack 1, win 29, length 430: HTTP: GET /path/to/dt-execute-queue.php HTTP/1.1
E...
C@.;..%.D:..r.8}..P.&..EK..P...,6..GET /path/to/dt-execute-queue.php HTTP/1.1
Host: www.mondomaine.com
Connection: Keep-Alive
Accept-Encoding: gzip
CF-IPCountry: CA
X-Forwarded-For: IPV6_CLIENT
CF-RAY: 2f854afec4025625-ORD
X-Forwarded-Proto: http
CF-Visitor: {"scheme":"http"}
User-Agent: EasyCron/1.0 (https://www.easycron.com/)
CF-Connecting-IP: IPV6_CLIENT

cela vient d'une IPV4_CLOUDFLARE mais le client est en ipv6

plus qu'à travailler sur la zone dns alors

Merci,
Mick

Dernière modification par mickbad (Le 27/10/2016, à 11:30)

donut · Le 27/10/2016, à 11:10

Attention aux ips c'est une donnée privée.
En fait il faudrait faire un tcpdump sur le port 80 pour voir si c'est uniquement de l'IPv4 qui passe.
Mais la recherche des en-têtes X-Forwarded-For était une bonne idée aussi !

mickbad · Le 27/10/2016, à 11:34

Merci de me avoir fait remarquer pour les ips, je n'ai pas fait attention
Du coup, j'ai anonymisé le tout (enfin je l'espère)

# tcpdump -c 20000 -s 0 -i eth0 -A tcp port 80 | grep X-Forwarded-For

Cette commande me donne la même chose : des mélanges d'ipv4 et v6
Cela se confirme.

Reste à repérer l'entrée AAAA dans la zone et sur ce que j'ai fourni plus haut (venant de cloudflare) je n'ai pas d'entrée AAAA. C'est peut-être eux que ajoute sans le montrer. A voir dans les interfaces.

Mick

mickbad · Le 27/10/2016, à 13:48

Alors, merci le topic est [RESOLU]

Cela venait effectivement du domaine et en particulier de cloudflare que j'utilise. En effet peu importe la zone dns qu'on met dessus, une option ouvre la fonctionnalité IPv6 dans les paramètre du domaine traité !

Sur les interfaces Cloudflare : choisir domaine.com > Network (onglet / bouton)
- mettre à OFF l'option IPv6 Compatibility Enable IPv6 support and gateway.
- mettre Overwrite Headers dans l'option Pseudo IPv4 Adds an IPv4 header to requests when a client is using IPv6, but the server only supports IPv4.

Après quelques secondes, le dig AAAA ne montre plus d'entrée pour mon domaine.com et au niveau des logs, je n'ai pu d'ipv6 (les gens se connectant avec ont une pseudo IP)

Donc ma première méthode consistant à inhiber la fonctionnalité ipv6 du serveur n'était pas nécessaire du fait que j'utilise Cloudflare qui est maître dans les redirections. Cela a ses avantages et inconvénients.

Si cela peut servir à quelqu'un d'autre

Et tout cas merci à ceux qui ont posé les bonnes questions et donut pour avoir bien aiguillé dans la compréhension du sujet !

Mick

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#1 Le 26/10/2016, à 17:10

[RESOLU] Obliger les navigateurs à se connecter en ipv4

#2 Le 26/10/2016, à 20:51

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#3 Le 27/10/2016, à 08:29

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#4 Le 27/10/2016, à 08:43

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#5 Le 27/10/2016, à 09:07

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#6 Le 27/10/2016, à 09:27

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#7 Le 27/10/2016, à 09:27

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#8 Le 27/10/2016, à 09:30

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#9 Le 27/10/2016, à 09:31

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#10 Le 27/10/2016, à 09:33

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#11 Le 27/10/2016, à 09:35

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#12 Le 27/10/2016, à 09:51

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#13 Le 27/10/2016, à 10:37

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#14 Le 27/10/2016, à 10:42

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#15 Le 27/10/2016, à 11:03

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#16 Le 27/10/2016, à 11:10

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#17 Le 27/10/2016, à 11:34

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

#18 Le 27/10/2016, à 13:48

Re : [RESOLU] Obliger les navigateurs à se connecter en ipv4

Pied de page des forums