Routage du trafic IPv6 public via le tunnel OpenVPN


13

Ce que j'essaie de faire est d'acheminer le trafic IPv6 à travers un tunnel vpn. De cette façon, je devrais pouvoir utiliser IPv6 dans un réseau qui ne prend pas en charge IPv6.

J'ai un VPS qui a un bloc IPv6 assigné. Une partie de ce bloc que je veux utiliser pour les clients openvpn. La plage que j'avais en tête était 2001:db8::111:800:0/112(le préfixe est anonyme), car openvpn ne prend en charge que / 64 et / 112 en tant que sous-réseaux.

IPv6 à travers le tunnel fonctionne déjà, depuis le client, je peux envoyer une requête ping au serveur ( 2001:db8::111:800:1), et également des interfaces sur le serveur ( 2001:db8::111:100:100et 2001:db8:216:3dfa:f1d4:81c0).

Cependant, lorsque j'essaie d'envoyer une requête ping à google.com à partir du client, je n'obtiens aucune réponse (délai d'expiration du ping). Afin de déboguer ce problème, j'ai utilisé tcpdump pour capturer le trafic sur le serveur, et je peux voir les paquets ping sortir, mais aucune réponse ne revient. L'ajout de règles de journal à ip6tables montre la même chose, les paquets sortent, mais rien ne vient.

J'ai utilisé un outil traceroute en ligne qui obtient un délai d'expiration de mon serveur. J'ai également essayé de définir l'IP directement sur l'interface, ce qui rend l'ip ( 2001:db8::111:800:1001) accessible, donc je pense que c'est un problème de routage.

J'ai activé le transfert pour ipv6 via /proc/sys/net/ipv6/conf/all/forwarding. ip6tables a une politique autorisant toutes les chaînes.

Ma question est, que faut-il exactement pour que Linux accepte ce paquet pour une adresse IP qui n'est pas affectée à une interface et le route plus loin? Un itinéraire qui existe ne semble pas suffisant.

Voici la configuration de mon client et de mon serveur. Veuillez lui faire savoir si plus d'informations sont nécessaires.

Client

# ip -6 addresses
10: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 100
    inet6 2001:db8::111:800:1001/112 scope global 
       valid_lft forever preferred_lft forever

# ip -6 routes
2001:db8::111:800:0/112 dev tun0  proto kernel  metric 256 
2000::/3 dev tun0  metric 1024 

Serveur

# ip -6 address
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qlen 1000
    inet6 2001:db8:216:3dfa:f1d4:81c0/64 scope global dynamic 
       valid_lft 86254sec preferred_lft 14254sec
    inet6 2001:db8::111:100:100/128 scope global 
       valid_lft forever preferred_lft forever
12: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qlen 100
    inet6 2001:db8::111:800:1/112 scope global 
       valid_lft forever preferred_lft forever

# ip -6 route
2001:db8::111:100:100 dev eth0  proto kernel  metric 256 
2001:db8::111:800:0/112 dev tun0  proto kernel  metric 256 
2001:db8::/64 dev eth0  proto kernel  metric 256  expires 86194sec
default via fe80::230:48ff:fe94:d6c5 dev eth0  proto ra  metric 1024  expires 1594sec

Possible que vous recherchez POSTROUTING ... MASQUERADEdans le nattableau. Mais je ne suis pas sûr de bien comprendre. Essayez-vous de tunneler le trafic IPv6? Si oui, avez-vous mis en place les installations respectives? Les -p ipv6paquets sont-ils autorisés dans les règles IPv4 (!)?
0xC0000022L

Avez-vous la configuration IP du routeur (sur eth0)? Contrôlez-vous le routeur? (pouvez-vous ajouter des itinéraires?)
ysdx

Essayez d'utiliser la TRACEcible de table brute iptables (peut-être pas tellement ici) ip neighbour, et ip route get. Veuillez également spécifier qui envoie une requête ping google.ca.
pilona

Pinging google.com ou goole.com.?
totti

@totti google.com, était une faute de frappe
Ikke

Réponses:


12

Vous devez dire à votre routeur d'utiliser votre serveur pour ce sous-réseau VPN: la bonne solution à votre problème est d'ajouter un itinéraire sur le routeur pour le sous-réseau OpenVPN.

Si vous ne pouvez pas le faire parce que vous ne pouvez pas toucher le routeur, une autre solution consiste à configurer un proxy NDP pour les clients sur le eth0lien.

Comme vous utilisez un VPS, vous ne pouvez probablement pas ajouter de routes au routeur: vous devez probablement utiliser la deuxième solution.

Ajouter un itinéraire pour le sous-réseau

La bonne solution à votre problème est de dire au routeur que le sous-réseau VPN doit être routé via le serveur OpenVPN (c'est pour Linux):

ip route add 001:db8::111:800::/112 via 2001:db8::111:100:100

Vous devez activer le transfert IPv6 sur le serveur:

sysctl sys.net.ipv6.conf.all.forwarding=1

Proxy NDP

Il semble que le routeur soit configuré pour envoyer toute votre plage IPv6 sur le eth0lien: vous pouvez configurer un proxy NDP.

Vous devriez voir des requêtes NDP sur l' eth0interface du serveur pour votre sous-réseau OpenVPN lorsque vous essayez d'accéder au reste d'Internet à partir du client.

Vous devez également activer le transfert IPv6 sur le serveur et le proxy NDP:

sysctl -w net.ipv6.conf.all.proxy_ndp = 1

proxy NDP de sous-réseau

Le noyau Linux ne permet pas d'ajouter un proxy NDP pour un sous-réseau mais uniquement pour des adresses IP individuelles. Vous pouvez utiliser un démon (tel que ndppd pour configurer un proxy NDP pour un sous-réseau entier (jamais utilisé).

Par proxy NDP IP

Une autre solution consiste à peut ajouter un proxy NDP pour chaque IPv6 du sous-réseau VPN:

for i in $(seq 0 65535) ; do
  ip neigh add proxy 2001:db8::111:800:$(printf %x $i) dev tun0
done

Cela devrait fonctionner car vous avez un petit nombre d'IP compatible dans le sous-réseau OpenVPN.

Proxy NDP dynamique avec crochets OpenVPN

Vous devriez pouvoir utiliser des hooks OpenVPN pour ajouter dynamiquement un proxy NDP.

Ajoutez un hook dans la configuration du serveur OpenVPN:

learn-address /etc/openvpn/learn-address

Avec le learn-addressscript suivant :

#!/bin/sh

action="$1"
addr="$2"

case "$action" in
    add | update)
        ip neigh replace proxy "$addr" dev tun0
        ;;
    delete)
        ip neigh del proxy "$addr" dev tun0
        ;;
esac

Voir ce fil .

Réponse courte

for i in $(seq 0 65535) ; do
  ip neigh add proxy 2001:db8::111:800:$(printf %x $i) dev tun0
done

1
Merci, je vais y jeter un œil. Je comprends maintenant le problème. ipsidixit.net/2010/03/24/239 contient plus de détails à ce sujet.
Ikke

J'ai l'ip du client comme proxy voisin. J'ai activé sys.net.ipv6.conf.all.proxy_ndp, mais je ne parviens toujours pas à envoyer une requête ping à google.com. Lorsque je vérifie le serveur, je vois des paquets de sollicitations ndp entrant sur eth0, mais aucune publicité ne sort.
Ikke

1
Après l'installation et la configuration de npd6, cela fonctionne soudainement!
Ikke
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.