3 votes

Quels sont les itinéraires appropriés à pousser pour un serveur OpenVPN ponté?

J'ai configuré un serveur OpenVPN sur une machine ayant une adresse IP privée de 10.0.0.13. La passerelle se trouve à 10.0.0.2, et distribue des adresses 10.0.0.* aux autres machines sur le réseau. Le VPN est configuré en mode pont. Mon fichier /etc/network/interfaces ressemble à ceci :

# Activer automatiquement ces interfaces
auto lo br0

# Interface de réseau local
iface lo inet loopback

# Connexion en pont
iface br0 inet static
    address         10.0.0.13
    bridge_ports    eth0
    bridge_stp      on
    broadcast       10.0.0.255
    gateway         10.0.0.2
    netmask         255.255.255.0
    network         10.0.0.0

# Interface réseau principale
iface eth0 inet manual
    up ifconfig $IFACE 0.0.0.0 up
    up ip link set $IFACE promisc on
    down ip link set $IFACE promisc off
    down ifconfig $IFACE down

Le fichier de configuration du serveur (/etc/openvpn/server.conf) ressemble à ceci :

port 1194
proto udp
dev tap0
up "/etc/openvpn/up.sh br0"
down "/etc/openvpn/down.sh br0"
ca ca.crt
cert VPNserver.crt
key VPNserver.key
dh dh1024.pem
ifconfig-pool-persist ipp.txt

server-bridge 10.0.0.13 255.255.255.0 10.0.0.200 10.0.0.219
push "route 10.0.0.2 255.255.255.0"

push "redirect-gateway def1 bypass-dhcp"
client-to-client
keepalive 10 120
tls-auth ta.key 0
comp-lzo
max-clients 20
user nobody
group nogroup
persist-key
persist-tun
status openvpn-status.log
log-append  /var/log/openvpn.log
verb 3
crl-verify crl.pem

Je pense que server-bridge et la ligne en dessous pourraient nécessiter un ajustement. OpenVPN devrait-il créer un sous-réseau pour lui-même et pour les clients connectés ? Au début, j'étais sous l'impression que OpenVPN pouvait attribuer des adresses IP dans le même sous-réseau tant qu'elles se trouvaient en dehors de la plage DHCP du routeur; maintenant je ne suis plus sûr.

Quoi qu'il en soit, voici les symptômes de la configuration actuelle. La machine cliente (qui se trouve dans un réseau 10.6.0.0 -- vous le verrez dans la sortie à suivre) peut se connecter, mais seule l'IP du serveur OpenVPN est pingable et je ne peux pas naviguer sur internet. Je me connecte depuis une interface CLI Linux ; voici une partie de la sortie qui me laisse penser que le routage est le problème. J'ai mis en gras la sortie qui me semble pertinente.

Ven Juin  3 12:54:51 2011 [VPNserver] Connexion avec [AF_INET]SERVER.PUBLIC.IP.ADDRESS:1194 initiée  
Ven Juin  3 12:54:53 2011 ENVOI CONTROL [VPNserver]: 'DEMANDE_PUSH' (statut=1)  
Ven Juin  3 12:54:53 2011 PUSH: Message de contrôle reçu : 'REPONSE_PUSH,route 10.0.0.2 255.255.255.0,redirect-gateway def1 bypass-dhcp,route-gateway 10.0.0.13,ping 10,ping-restart 120,ifconfig 10.0.0.201 255.255.255.0'  
Ven Juin  3 12:54:53 2011 IMPORTATION DES OPTIONS: timers et/ou délais modifiés  
Ven Juin  3 12:54:53 2011 IMPORTATION DES OPTIONS: options --ifconfig/up modifiées  
Ven Juin  3 12:54:53 2011 IMPORTATION DES OPTIONS: options de routage modifiées  
Ven Juin  3 12:54:53 2011 IMPORTATION DES OPTIONS: options relatives au routage modifiées  
Ven Juin  3 12:54:53 2011 ROUTE default_gateway=10.6.0.1  
Ven Juin  3 12:54:53 2011 Dispositif TUN/TAP tap0 ouvert  
Ven Juin  3 12:54:53 2011 Longueur de la file d'attente TUN/TAP définie à 100  
Ven Juin  3 12:54:53 2011 /sbin/ifconfig tap0 10.0.0.201 masque 255.255.255.0 mtu 1500 broadcast 10.0.0.255  
Ven Juin  3 12:54:53 2011 /sbin/route add -net SERVER.PUBLIC.IP.ADDRESS masque 255.255.255.255 gw 10.6.0.1  
**SIOCADDRT: Fichier existant  
Ven Juin  3 12:54:53 2011 ERREUR : échec de la commande d'ajout de route Linux : le programme externe a quitté avec un statut d'erreur : 7**  
Ven Juin  3 12:54:53 2011 /sbin/route add -net 0.0.0.0 masque 128.0.0.0 gw 10.0.0.13  
Ven Juin  3 12:54:53 2011 /sbin/route add -net 128.0.0.0 masque 128.0.0.0 gw 10.0.0.13  
**Ven Juin  3 12:54:53 2011 /sbin/route add -net 10.0.0.2 masque 255.255.255.0 gw 10.0.0.13
route : le masque de réseau ne correspond pas à l'adresse de route**  
Utilisation : route [-nNvee] [-FC] []           Liste des tables de routage du noyau  
   route [-v] [-FC] {ajouter|supprimer|vider} ...  Modifier la table de routage pour AF.  

   route {-h|--aide} []              Syntaxe d'utilisation détaillée pour AF spécifié.  
   route {-V|--version}                  Afficher la version/l'auteur et quitter.  
  -v, --verbeux            être verbeux  
  -n, --numérique            ne pas résoudre les noms  
  -e, --étendre             afficher d'autres/informations supplémentaires  
  -F, --fib                afficher la base d'information de transfert (par défaut)  
  -C, --cache              afficher le cache de routage au lieu de la FIB  

  =Utilisez '-A ' ou '--'; par défaut : inet  
  Liste des familles d'adresse possibles (qui supportent le routage) :  
   inet (Internet DARPA) inet6 (IPv6) ax25 (AMPR AX.25)  
   netrom (AMPR NET/ROM) ipx (Novell IPX) ddp (Appletalk DDP)  
   x25 (CCITT X.25)  
**Ven Juin  3 12:54:53 2011 ERREUR : échec de la commande d'ajout de route Linux : le programme externe a quitté avec un statut d'erreur : 4**  
Ven Juin  3 12:54:53 2011 ID du groupe défini sur nogroup  
Ven Juin  3 12:54:53 2011 ID utilisateur défini sur nobody  
Ven Juin  3 12:54:53 2011 Séquence d'initialisation terminée  

Donc, je cherche à :

  1. Faire disparaître ces erreurs
  2. Pouvoir accéder aux machines autres que le serveur OpenVPN sur le réseau 10.0.0.0
  3. Routage de tout le trafic (navigation internet, etc) à travers le VPN

2voto

jammus Points 1796

Si vous faites du bridging, vous ne devriez probablement pas pousser de routes.

1voto

amit-agrawal Points 1005

D'accord, techniquement @Zoredache a raison. Ma question était, "Quelles sont les routes appropriées à pousser pour un serveur OpenVPN en pont?" et je ne devrais pas pousser route 10.0.0.2 255.255.255.0 (qui devrait probablement être route 10.0.0.0 255.255.255.0 de toute façon). En supprimant cette ligne, j'ai résolu la première partie de mon problème.

La deuxième partie de mon problème (ne pas pouvoir pinguer d'autres machines sur le réseau 10.0.0.0) était liée à un détail que j'avais omis de mentionner, à savoir que ce serveur se trouve sur une machine virtuelle VMWare. Grâce à ce billet de blog, j'ai découvert que "le commutateur virtuel ESXi rejette les paquets en mode promiscuité par défaut", et j'ai appris comment configurer la machine virtuelle pour ne pas le faire.

Je n'ai pas pu atteindre le troisième objectif de faire passer tout le trafic par le VPN, mais j'ai décidé que ce n'était pas crucial pour ce déploiement particulier. Les commentaires dans la configuration par défaut suggèrent qu'en décommentant push "redirect-gateway def1 bypass-dhcp" "tous les clients seront configurés pour rediriger leur passerelle réseau par défaut à travers le VPN, faisant passer tout le trafic IP comme la navigation web et les requêtes DNS par le VPN," mais lorsque je l'ai décommenté, je n'ai pas pu sortir du réseau du tout.

0voto

Marcelo Pacheco Points 103

Lorsque vous utilisez un OpenVPN routé, l'interface est implicite. Cependant, lorsque vous utilisez un OpenVPN en mode ponté, vous ne pouvez plus supposer quoi que ce soit de manière implicite. Il devrait être possible d'informer à travers quelle IP passe la route. Par exemple (en ligne de commande Linux) : ip ro add 8.0.0.0/8 via 1.2.3.4.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X