La Fibre
Télécom => Réseau => 
VPN => Discussion démarrée par: lechercheur123 le 27 janvier 2019 à 07:41:04
-
Bonjour,
J'ai chez moi (enfin chez ma mère pour être exact) un petit serveur sous Débian relié à une Livebox 4. Ce serveur est dans la DMZ (pour IPv4), et j'ai ouvert tous les ports pour IPv6 sur la Livebox. J'y ai installé un serveur OpenVPN auquel je peux y accéder en IPv4 et IPv6. Mais c'est à l'intérieur du tunnel que ça coince. En effet, d'après mes captures Wireshark, la Livebox diffuse uniquement un préfixe de 64 bits de long (le 2a01:XXXX:XXXX:XX00::/64) dans les RA alors que la Livebox dispose d'un /56. J'aimerai donc pouvoir utiliser un sous-réseau disponible (2a01:XXXX:XXXX:XX01::/64 par exemple) pour les clients du VPN.
Je ne suis pas un expert en réseau, mais si j'ai bien compris je dois demander un préfixe à la Livebox au travers de DHCPv6-PD. J'ai donc ajouté ceci à mon fichier interfaces dans la section "iface enp4s0 inet6 auto" :
dhcp 1
request_prefix 1
Mais ensuite je suis bloqué. Comment savoir quel préfixe a été délégué par la Livebox (si il a réellement été délégué) ? Y a-t-il autre chose à faire ?
-
Bonjour,
pas sur que la livebox ne délègue un préfixe il me semble que la livebox n'a qu'un /64 pour elle. https://lafibre.info/remplacer-livebox/routeur-derriere-la-livebox-ipv6/msg588823/#msg588823
-
Ce n'est pas possible actuellement. La livebox ne sait pas déléguer les autres /64.
La seul alternative est de remplacer la livebox par son propre équipement.
-
Merci pour vos réponses.
C'est quand même dommage de n'utiliser qu'un /64 alors que la livebox dispose d'un /56. J'imagine qu'Orange a préféré anticiper pour des usages futurs.
Malheureusement je ne peux pas remplacer la box car elle n'est pas chez moi et je suis actuellement à plusieurs milliers de km. Tant pis, on va faire avec.
-
Il me semble aussi que pour assigner des adresses aux clients dans le LAN, la Livebox utilise le SLAAC, donc le même /64 pour tous les clients.
Le DHCPv6-PD c'est pour la liaison CPE (livebox) <> Orange.fr
-
Effectivement, c'est SLAAC qui est utilisé. Mais DHCPv6 est utilisé pour certaines choses : j'ai fait quelques captures et on remarque des paquets "Information request" avec ces requêtes :
Frame 2294: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface 0
Ethernet II, Src: Apple_ea:XX:XX (40:cb:c0:ea:XX:XX), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Internet Protocol Version 6, Src: fe80::fd:XXXX:XXXX:XXXX, Dst: ff02::1:2
User Datagram Protocol, Src Port: 546, Dst Port: 547
DHCPv6
Message type: Information-request (11)
Transaction ID: 0x96e5db
Client Identifier
Option Request
Option: Option Request (6)
Length: 4
Value: 00170018
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Elapsed time
Donc DHCPv6 est utilisé, mais pas DHCPv6-PD (en tout cas pas dans le LAN)
-
Et la un paquet RA :
Internet Control Message Protocol v6
Type: Router Advertisement (134)
Code: 0
Checksum: 0xcce8 [correct]
[Checksum Status: Good]
Cur hop limit: 64
Flags: 0x48, Other configuration, Prf (Default Router Preference): High
0... .... = Managed address configuration: Not set
.1.. .... = Other configuration: Set
..0. .... = Home Agent: Not set
...0 1... = Prf (Default Router Preference): High (1)
.... .0.. = Proxy: Not set
.... ..0. = Reserved: 0
Router lifetime (s): 600
Reachable time (ms): 0
Retrans timer (ms): 0
ICMPv6 Option (Prefix information : 2a01:XXXX:XXXX:cb00::/64)
Type: Prefix information (3)
Length: 4 (32 bytes)
Prefix Length: 64
Flag: 0xc0, On-link flag(L), Autonomous address-configuration flag(A)
Valid Lifetime: 1800
Preferred Lifetime: 600
Reserved
Prefix: 2a01:XXXX:XXXX:cb00::
ICMPv6 Option (Recursive DNS Server fe80::da7d:7fXX:XXXX:XXXX)
Type: Recursive DNS Server (25)
Length: 3 (24 bytes)
Reserved
Lifetime: 600
Recursive DNS Servers: fe80::da7d:7fXX:XXXX:XXXX
ICMPv6 Option (DNS Search List Option home)
Type: DNS Search List Option (31)
Length: 2 (16 bytes)
Reserved
Lifetime: 600
Domain Names: home
Padding
ICMPv6 Option (MTU : 1500)
Type: MTU (5)
Length: 1 (8 bytes)
Reserved
MTU: 1500
ICMPv6 Option (Source link-layer address : d8:7d:7f:XX:XX:XX)
Type: Source link-layer address (1)
Length: 1 (8 bytes)
Link-layer address: Sagemcom_XX:XX:XX (d8:7d:7f:XX:XX:XX)
-
Effectivement, c'est SLAAC qui est utilisé. Mais DHCPv6 est utilisé pour certaines choses : j'ai fait quelques captures et on remarque des paquets "Information request" avec ces requêtes :
Frame 2294: 98 bytes on wire (784 bits), 98 bytes captured (784 bits) on interface 0
Ethernet II, Src: Apple_ea:XX:XX (40:cb:c0:ea:XX:XX), Dst: IPv6mcast_01:00:02 (33:33:00:01:00:02)
Internet Protocol Version 6, Src: fe80::fd:XXXX:XXXX:XXXX, Dst: ff02::1:2
User Datagram Protocol, Src Port: 546, Dst Port: 547
DHCPv6
Message type: Information-request (11)
Transaction ID: 0x96e5db
Client Identifier
Option Request
Option: Option Request (6)
Length: 4
Value: 00170018
Requested Option code: DNS recursive name server (23)
Requested Option code: Domain Search List (24)
Elapsed time
Donc DHCPv6 est utilisé, mais pas DHCPv6-PD (en tout cas pas dans le LAN)
Apple_ea:XX:XX c'est pas la Livebox, c'est ta machine.
-
Apple_ea:XX:XX c'est pas la Livebox, c'est ta machine.
Je sais. (mais c'est vrai, du coup ce n'est pas très pertinent)
Par contre dans le RA on peut voir :
.1.. .... = Other configuration: Set
Ce qui signifie que DHCPv6 est utilisé pour recevoir quelques infos (mais probablement pas pour assigner des IPv6)
-
Oui, c'est un 3° usage de DHCPV6 (le mode stateless) qui permet, sans délivrer d'adresses, de quand même fournir aux clients des resolvers DNS et un nom de domaine.
Ce mode est signalé par la LiveBox dans ses RA, par les flags 'Managed address configuration: Not set' et 'Other configuration: Set'.
Cela a un intérêt si le client ne sait pas récupérer ces deux informations dans les Router Advertisements émis par la Livebox. Il a la possibilité dans ce cas de faire une requête DHCP pour les obtenir.
Je ne connais pas assez OpenVPN, mais il y a peut-être moyen de disribuer des adresses d'un unique /64 à ses clients : https://community.openvpn.net/openvpn/wiki/IPv6#SplittingasingleroutableIPv6netblock
-
Oui, c'est un 3° usage de DHCPV6 (le mode stateless) qui permet, sans délivrer d'adresses, de quand même fournir aux clients des resolvers DNS et un nom de domaine.
Ce mode est signalé par la LiveBox dans ses RA, par les flags 'Managed address configuration: Not set' et 'Other configuration: Set'.
Cela a un intérêt si le client ne sait pas récupérer ces deux informations dans les Router Advertisements émis par la Livebox. Il a la possibilité dans ce cas de faire une requête DHCP pour les obtenir.
Merci pour les explications. En effet, seuls les appareils Apple effectue ces demandes (sur mon réseau en tout cas).
Je ne connais pas assez OpenVPN, mais il y a peut-être moyen de disribuer des adresses d'un unique /64 à ses clients : https://community.openvpn.net/openvpn/wiki/IPv6#SplittingasingleroutableIPv6netblock
Oui mais c'est moyennement propre, ça casse beaucoup de choses. Sinon je vais peut-être monter un tunnel TAP au lieu de TUN (VPN de niveau 2 au lieu de 3) mais bon cela a aussi des désavantages. Je ne vais quand même pas être obligé du faire du NAT (j'ai dû le faire sur un VPS chez OVH qui n'a qu'un /128, j'en pleure encore la nuit).
-
Sinon y'a des tas de protos moins nazes qu'oVPN pour du tunnel ptp, genre L2TP. On a ça chez MilkyWan, ça route de la v6 sans souci. GRE sinon, si vous avez une IP Publique.
-
C'est si nul que ça OpenVPN ? (j'avoue ne pas y connaître grand chose, et OpenVPN est le seul VPN que j'ai déjà testé)
Si j'ai bien compris, L2TP c'est un VPN niveau 2. OpenVPN sait le faire ça aussi (enfin, normalement)
-
Oui mais c'est moyennement propre, ça casse beaucoup de choses. Sinon je vais peut-être monter un tunnel TAP au lieu de TUN (VPN de niveau 2 au lieu de 3) mais bon cela a aussi des désavantages. Je ne vais quand même pas être obligé du faire du NAT (j'ai dû le faire sur un VPS chez OVH qui n'a qu'un /128, j'en pleure encore la nuit).
Il n'y a pas de « NAT », si c'est un tunnel avec un pont ethernet c'est comme si la machine distante était physiquement présente sur le LAN. Donc la machine distante obtiendra son IPv6 avec le SLAAC.
-
Oui, je me suis mal exprimé. C'est soit j'utilise TAP (niveau 2), soit je fais du NAT (avec une interface TUN).
-
Oui, je me suis mal exprimé. C'est soit j'utilise TAP (niveau 2), soit je fais du NAT (avec une interface TUN).
Pas besoin, il suffit de router une IP dans le /64 au client.
-
Je fais comment ? Je mets plusieurs IP sur mon interface ethernet ? (à la limite je peux en mettre genre 16 à la suite, ça peut me faire un /124, non ? comme ça je pourrai avoir 13 clients simultanèment sur mon VPN, non ?)
-
Je fais comment ? Je mets plusieurs IP sur mon interface ethernet ? (à la limite je peux en mettre genre 16 à la suite, ça peut me faire un /124, non ? comme ça je pourrai avoir 13 clients simultanèment sur mon VPN, non ?)
Il faut que la machine sur le LAN qui sert de relai réponde à l'NDP pour toutes les adresses que tu veux utiliser, autoriser ces adresses dans le pare-feu interne de OpenVPN puis router les adresses dans le tunnel.
-
Ça y est, j'ai réussi !
Merci pour votre aide, elle m'a été d'une grande utilité !
Du coup, pour résumer, ma conf ressemble à ça (je ne mets que les parties utiles) :
openvpn.conf
#IPv6
server-ipv6 2a01:XXXX:XXXX:XX00::1:0/112
tun-ipv6
push tun-ipv6
push "route-ipv6 2a01:XXXX:XXXX:XX00::/64"
push "route-ipv6 2000::/3"
Ensuite j'ai fait un petit script (trouvé sur le net) pour mettre le proxy sur les adresses de 2a01:XXXX:XXXX:XX00::1:1000 à 2a01:XXXX:XXXX:XX00::1:112C (soit les 300 premières adresses après ::1:1000 qui est la première utilisée par OpenVPN, les autres sont incrèmentées à partir de celle-ci) :
#!/bin/sh
for i in $(seq 4096 4396) ; do
ip neigh add proxy 2a01:XXXX:XXXX:XX00::1:$(printf %x $i) dev enp4s0
done
Et c'est tout ! (bon il faut aussi autoriser le forwarding et npd_proxy dans sysctl)
Petite note perso : J'ai beaucoup vu sur Internet qu'il fallait utiliser la commande "ip neigh add proxy..." avec tun0 comme interface. Or cela ne marchait pas pour moi. J'ai simplement remplacé tun0 par enp4s0 et tout est devenu fonctionnel !
-
C'est si nul que ça OpenVPN ? (j'avoue ne pas y connaître grand chose, et OpenVPN est le seul VPN que j'ai déjà testé)
disons que c'est lourding OpenVPN. Si tu veux du light mais avec du chiffrement il y a Wireguard (https://www.wireguard.com) (plus simple, plus performant).
-
Je ne connaissais pas Wireguard, ça a l’air récent (pas tant que ça en fait, je viens de voir que le premier commit a été fait le 25/06/2016). L’avantage de OpenVPN c’est qu’il est pris en charge par mon routeur, qui fait tourner un client OpenVPN. C’est pratique car ça permet à des appareils ne pouvant pas faire tourner de client VPN de pouvoir s’y connecter. Mon routeur accepte L2TP et PPTP aussi. Sinon j’ai un accès SSH dessus donc je devrai en théorie pouvoir installer un client Wireguard dessus, mais honnêtement je n’ai pas très envie de m’embêter pour l’instant.
Après c’est vrai que j’ai eu quelques soucis de performances avec OpenVPN, mon serveur n’étant pas très véloce. Mais il faudrait que je teste de nouveau pour voir à quel débit je suis limité