Auteur Sujet: Tunnel Hurricane Electric: peut pinger mais pas de trafic (Linux Debian 10) (Lu 4992 fois)

thenico · « **Réponse #12 le:** 04 juin 2020 à 00:39:59 »

As-tu vérifier le pare-feu ? iptables-save && ip6tables-save
Quelque chose bouffe le flux tcp dans le sens he => toi.

Sinon mtu à 1280 c'est la taille minimal autorisé en ipv6.

StardustOne · « **Réponse #13 le:** 04 juin 2020 à 18:57:07 »

J'ai set MTU à 1280 coté client et coté serveur.

flush complet iptables et ip6tables
ifdown he-ipv6
ifup he-ipv6
toujours pareil

cali · « **Réponse #14 le:** 04 juin 2020 à 19:54:50 »

Citation de: StardustOne le 04 juin 2020 à 18:57:07

J'ai set MTU à 1280 coté client et coté serveur.

Code: [Sélectionner]

$ ping -M do -s 1232 $IP

Depuis un hôte distant.

IP c'est l'adresse que tu as assignée à ton interface bien sûr.

StardustOne · « **Réponse #15 le:** 04 juin 2020 à 20:13:23 »

Code: [Sélectionner]

remote-server $ ping6 -c3 -M do -s 1232 2001:1111:2222:3333::2
PING 2001:1111:2222:3333::2(2001:1111:2222:3333::2) 1232 data bytes
1240 bytes from 2001:1111:2222:3333::2: icmp_seq=1 ttl=59 time=3.96 ms
1240 bytes from 2001:1111:2222:3333::2: icmp_seq=2 ttl=59 time=3.90 ms
1240 bytes from 2001:1111:2222:3333::2: icmp_seq=3 ttl=59 time=4.48 ms

--- 2001:1111:2222:3333::2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 5ms
rtt min/avg/max/mdev = 3.899/4.110/4.477/0.270 ms

Le 'mtr' est plus intéressant:

Code: [Sélectionner]

remote (xxxxxxxxxxxxxxxx)                                                                           2020-06-04T20:15:29+0200
Keys:  Help   Display mode   Restart statistics   Order of fields   quit
                                                                                                     Packets               Pings
 Host                                                                                              Loss%   Snt   Last   Avg  Best  Wrst StDev
 1. AS12876  2001:bc8:1200:6::1 (2001:bc8:1200:6::1)                                                0.0%    56    0.8   0.8   0.7   1.8   0.1
 2. AS12876  2001:bc8:1000:1:: (2001:bc8:1000:1::)                                                  0.0%    56    0.9   0.7   0.6   1.1   0.1
 3. AS12876  2001:bc8:400:1::150 (2001:bc8:400:1::150)                                             13.0%    55    1.6   1.4   1.2   1.7   0.2
 4. AS???    he.par.franceix.net (2001:7f8:54::10)                                                  0.0%    55    1.4   3.5   1.3  23.0   5.2
 5. AS6939   tserv1.par1.he.net (2001:470:0:7b::2)                                                  0.0%    55    3.0   3.5   2.0  19.0   2.3

Il me trouve pas le mtr on dirait et 2001:bc8:400:1::150 perd des paquets

kgersen · « **Réponse #16 le:** 04 juin 2020 à 20:26:38 »

vous tournez en rond la, le tracepath qu'il a fait avant montre que son mtu es a 1480.
tracepath utilise UDP et pas ICMP donc son tunnel fonctionne.

son souci est ailleurs, plus haut dans les couches.

essai:

Code: [Sélectionner]

curl -6v -D - http://curlmyip.netpuis

Code: [Sélectionner]

curl -6v -D - https://curlmyip.net

StardustOne · « **Réponse #17 le:** 04 juin 2020 à 20:32:45 »

Les 2 bloquent sans réponsse HTTP(S):

Code: [Sélectionner]

$ curl -6v -D -  http://curlmyip.net
* Expire in 0 ms for 6 (transfer 0x564fcb2a6f50)
[...]
*   Trying 2001:bc8:1200:6:208:a2ff:fe0c:631a...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x564fcb2a6f50)
* Connected to curlmyip.net (2001:bc8:1200:6:208:a2ff:fe0c:631a) port 80 (#0)
> GET / HTTP/1.1
> Host: curlmyip.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
^C

et

Code: [Sélectionner]

$ curl -6v -D -  https://curlmyip.net
* Expire in 0 ms for 6 (transfer 0x55f3eb215f50)
[...]
*   Trying 2001:bc8:1200:6:208:a2ff:fe0c:631a...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55f3eb215f50)
* Connected to curlmyip.net (2001:bc8:1200:6:208:a2ff:fe0c:631a) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
*   CAfile: none
  CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):

Une connexion 'ssh' qui n'aboutie pas :

Code: [Sélectionner]

$ ssh 2001:12:15:16::1 -v
OpenSSH_7.9p1 Debian-10+deb10u2, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 256: Applying options for *
debug1: Connecting to 2001:12:15:16::1 [2001:12:15:16::1] port 22.
debug1: Connection established.
debug1: identity file /home/stardust/.ssh/id_rsa type 0
debug1: identity file /home/stardust/.ssh/id_rsa-cert type -1
debug1: identity file /home/stardust/.ssh/id_dsa type -1
debug1: identity file /home/stardust/.ssh/id_dsa-cert type -1
debug1: identity file /home/stardust/.ssh/id_ecdsa type -1
debug1: identity file /home/stardust/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/stardust/.ssh/id_ed25519 type -1
debug1: identity file /home/stardust/.ssh/id_ed25519-cert type -1
debug1: identity file /home/stardust/.ssh/id_xmss type -1
debug1: identity file /home/stardust/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9p1 Debian-10+deb10u2

cali · « **Réponse #18 le:** 04 juin 2020 à 20:51:18 »

Citation de: kgersen le 04 juin 2020 à 20:26:38

vous tournez en rond la, le tracepath qu'il a fait avant montre que son mtu es a 1480.
tracepath utilise UDP et pas ICMP donc son tunnel fonctionne.

son souci est ailleurs, plus haut dans les couches.

1480 c'est le pmtu, si il y a du filtrage/qos ça ne veut pas dire que ça passera.

Son mtr et tracepath est peut-être en UDP mais la réponse c'est de l'ICMP.

Aussi, le problème semble être en réception plutôt qu'en émission.

cali · « **Réponse #19 le:** 04 juin 2020 à 20:59:31 »

Citation de: StardustOne le 04 juin 2020 à 20:32:45

Les 2 bloquent sans réponsse HTTP(S):

Pour moi c'est de la QoS de SFR, sûrement dans le CPE de merde.

Aussi, j'avais déjà eu de l'IPv6 sur une connexion SFR FTTH, il me semble que SFR faisait ça avec de l'encapsulation alors ça ne serait pas étonnant qu'il y ait un conflit si la configuration existe encore dans le CPE. C'est aussi crade de faire ça derrière un NAT qui de plus est géré par le CPE.

Je pense que tu devrais établir le tunnel avec un autre protocole et du chiffrement. Je ne sais pas si HE propose d'autres solutions.

StardustOne · « **Réponse #20 le:** 04 juin 2020 à 21:17:15 »

J'ai un serveur dédié dedibox avec de l'IPV6, j'ai bien réussit à configurer un VPN openvpn, puis comme c'était trop lent, un ipsec, mais c'est encore trop lent.

Quel protocole me permettrait de faire un tunnel sans bouffer trop de BP ? De préférence, quelque chose de documenté.

cali · « **Réponse #21 le:** 04 juin 2020 à 21:21:45 »

Citation de: StardustOne le 04 juin 2020 à 21:17:15

J'ai un serveur dédié dedibox avec de l'IPV6, j'ai bien réussit à configurer un VPN openvpn, puis comme c'était trop lent, un ipsec, mais c'est encore trop lent.

Quel protocole me permettrait de faire un tunnel sans bouffer trop de BP ? De préférence, quelque chose de documenté.

OpenVPN ça dépend de la manière dont il est configuré, il y a plusieurs topologies et beaucoup de configuration.

https://tinc-vpn.org/ fonctionne très bien.

kgersen · « **Réponse #22 le:** 04 juin 2020 à 21:30:38 »

Citation de: StardustOne le 04 juin 2020 à 21:17:15

Quel protocole me permettrait de faire un tunnel sans bouffer trop de BP ? De préférence, quelque chose de documenté.

wireguard . simple efficace. rapide.

j'utilise cela pour avoir de l'IPv6 sur certains sites (grace au /56 fournit avec la dedibox)

Par contre ne pas s'en servir des IPv6 en desktop (navigateurs web), les IPv6 d'Online sont souvent bloqués pour spam et autre.

StardustOne · « **Réponse #23 le:** 05 juin 2020 à 00:46:58 »

OK, j'ai désactivé l'IPV6 SLAAC sur mon dédié dédibox, puis j'ai activé mon tunnel HE.

Cela fonctionne très bien, mais maintenant il me reste à créer un VPN uniquement en IPV6 pour pouvoir y connecter mon client (desktop debian 10).

Est-ce possible déjà d'avoir un VPN uniquement ipv6 (je veut garder l'ipv4 de SFR) ?

Test:

Dans sysctl:

Code: [Sélectionner]

net.ipv6.conf.default.forwarding = 1
Conf coté peer wireguard Dedibox avec le tunnel HE:

Code: [Sélectionner]

[Interface]
Address = fd42:42:42::1/32
SaveConfig = true
PostUp = ip6tables -A FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -A POSTROUTING -o he-ipv6 -j MASQUERADE
PostDown = ip6tables -D FORWARD -i wg0 -j ACCEPT; ip6tables -t nat -D POSTROUTING -o he-ipv6 -j MASQUERADE
ListenPort = 1094
PrivateKey = xxx

[Peer]
PublicKey = yyy
AllowedIPs = fd42:42::/32

Coté desktop:

Code: [Sélectionner]

[Interface]
Address = fd42:42:42::1/64
PrivateKey = xxx
DNS = 80.67.169.12

[Peer]
PublicKey = sIaWVv4KJfNffFM5uypyqgHzau9A9Uq1y1ywvVUyilg=
Endpoint = 1.2.3.4:1094
AllowedIPs = 0.0.0.0/0
PersistentKeepalive = 21

Quand je lance

Code: [Sélectionner]

# wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -6 address add fd42:42:42::1/64 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] resolvconf -a tun.wg0 -m 0 -x
[#] wg set wg0 fwmark 51820
[#] ip -4 route add 0.0.0.0/0 dev wg0 table 51820
[#] ip -4 rule add not fwmark 51820 table 51820
[#] ip -4 rule add table main suppress_prefixlength 0
[#] sysctl -q net.ipv4.conf.all.src_valid_mark=1
[#] iptables-restore -n

Je ne lui ais pas demandé à toucher à mes routes ipv4.

J'ai essayé d'ajouter la route par défaut manuellement:

Code: [Sélectionner]

ip -6 route add ::0/0 dev wg0
J'ai bien mon ip Desktop wg0 en ipv6.

Code: [Sélectionner]

ip -6 r
::1 dev lo proto kernel metric 256 pref medium
fd42:42:42::/64 dev wg0 metric 1024 pref medium
fe80::/64 dev enp0s31f6 proto kernel metric 256 pref medium
default dev wg0 metric 1024 pref medium

Cela ne fonctionne pas:

Code: [Sélectionner]

$ ping fd42:42:42::2
PING fd42:42:42::2(fd42:42:42::2) 56 data bytes
ping: sendmsg: Required key not available
From fd42:42:42::1: icmp_seq=1 Destination unreachable: Address unreachable

Une idée ?