OpenVPN et routage et iptables
Objectif: Accéder aux périphériques réseau internes et parcourir le Web via le tunnel.
192.168.2.x = internal network
192.168.3.x = openvpn server
192.168.2.111 = openvpn server on internal network
[root@openvpn ~]# route
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.3.2 * 255.255.255.255 UH 0 0 0 tun0
192.168.3.0 192.168.3.2 255.255.255.0 UG 0 0 0 tun0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth0
link-local * 255.255.0.0 U 1002 0 0 eth0
default 192.168.2.254 0.0.0.0 UG 0 0 0 eth0
et
[root@openvpn ~]# cat /etc/openvpn/server.conf
port 1194 #- port
proto udp #- protocol
dev tun
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
reneg-sec 0
ca /etc/openvpn/easy-rsa/2.0/keys/ca.crt
cert /etc/openvpn/easy-rsa/2.0/keys/server.crt
key /etc/openvpn/easy-rsa/2.0/keys/server.key
dh /etc/openvpn/easy-rsa/2.0/keys/dh1024.pem
plugin /usr/share/openvpn/plugin/lib/openvpn-auth-pam.so /etc/pam.d/login #- Comment this line if you are using FreeRADIUS
#plugin /etc/openvpn/radiusplugin.so /etc/openvpn/radiusplugin.cnf #- Uncomment this line if you are using FreeRADIUS
client-cert-not-required
username-as-common-name
server 192.168.3.0 255.255.255.0
Push "redirect-gateway def1"
Push "dhcp-option DNS 8.8.8.8"
Push "dhcp-option DNS 8.8.4.4"
Push "route 192.168.2.0 255.255.255.0"
keepalive 5 30
comp-lzo
persist-key
persist-tun
status 1194.log
verb 3
et
client
dev tun
proto udp
remote 18.4.79.28 1194
resolv-retry infinite
nobind
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
persist-key
persist-tun
ca ca.crt
auth-user-pass
comp-lzo
reneg-sec 0
verb 3
Je peux me connecter juste bien et accéder à la boîte VPN. Cependant, je ne peux pas parcourir le Web ou accéder à d'autres périphériques réseau locaux.
J'ai des iptables. Ai-je besoin de règles de table IP ou est mon routage?
J'ai besoin de 192.168.3.0 pour accéder au 192.168.2.0 :)
Modifier: Vous avez oublié de mentionner, j'ai cet ensemble;
net.ipv4.conf.default.forwarding=1
ÉDITER:
J'ai utilisé ceci:
[root@openvpn ~]# iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source <SERVERIP>
[root@openvpn ~]# iptables -I INPUT 1 -p udp --dport 1194 -j ACCEPT
JE REÇOIS:
pinging 192.168.2.5
reply from 192.168.3.1 destination Host unreachable
Il y a deux choses dont vous aurez besoin pour vérifier et potentiellement corriger.
Premièrement, vous devez vous assurer que le transfert IP est activé dans le noyau. Le transfert IP permet au noyau de passer des paquets d'une interface à une autre. Vous pouvez vérifier cela avec ci-dessous:
$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0
Si vous voyez un 0 au lieu d'une 1, alors vous devez activer la transmission IP. Le moyen le plus simple et le plus fiable consiste à ajouter la ligne suivante à /etc/sysctl.conf (ou modifiez-le s'il existe déjà une entrée pour net.ipv4.ip_forward):
# Controls IP packet forwarding
net.ipv4.ip_forward = 1
Puis courez sysctl -p Pour recharger la configuration de ce fichier.
Ensuite, vous devrez configurer IPtables pour effectuer une traduction d'adresses réseau (NAT) sur les paquets provenant du VPN. Sinon, quand ces paquets sont envoyés eth0, tous les périphériques qui reçoivent les paquets ne savent pas comment parler (ils n'ont pas de route de retour à 192.168.3.0/24 via le serveur VPN). Vous pouvez configurer le NAT: static NAT (SNAT) et Masquerade. Snat est recommandé lorsque l'adresse IP de l'interface sortante (eth0 Dans votre cas) ne devrait pas changer. Le mode de mascarade est conçu pour les situations IP dynamiques telles que la connexion à distance ou d'autres configurations d'adresses attribuées dynamiquement (modems câblés, DSL, etc.). Les deux sont configurés de la même manière, cependant.
Pour Snat, vous ajouteriez une règle d'IPTABLES dans le sens de (note, j'ai utilisé 192.168.2.13 Parce que je ne connais pas l'IP que vous avez assigné à Eth0; Vous voudriez changer cela comme c'est approprié):
iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 192.168.2.13
Si l'adresse IP sur Eth0 n'est pas statique et fiable, vous utiliseriez Masquerade, qui ressemblerait à:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Je ne sais pas si vous utilisez AWS, mais assurez-vous de vous assurer que vous Désactiver la destination/la vérification de la source sur n'importe quelle instance AWS, vous pouvez utiliser pour exécuter ceci.
Faites un clic droit sur l'instance, la souris sur le réseau, puis il devrait y avoir une option là-bas.
Si cela ne vous aide pas, j'espère que cela aide quelqu'un d'autre.
Vous avez besoin d'une règle d'iPtables pour les clients VPN d'accéder au réseau.
D'abord, assurez-vous que votre système autorise NAT:
# Setup sysctl to enable NAT.
echo "# Allowing nat translation for VPN clients.
net.ipv4.conf.default.forwarding=1
net.ipv4.ip_forward=1" > "/etc/sysctl.d/openvpn.conf"
# load new sysctl config.
command sysctl -p "/etc/sysctl.d/openvpn.conf" > '/dev/null'
Ensuite, installez le NAT iptables pour le réseau VPN:
CURRENT_IP_RANGE="192.168.2"
command iptables -t nat -C POSTROUTING -s "${CURRENT_IP_RANGE}.0/24" \
-o 'eth0' -j MASQUERADE 2>'/dev/null' \
|| command iptables -t nat -A POSTROUTING -s "${CURRENT_IP_RANGE}.0/24" \
-o 'eth0' -j MASQUERADE
Ces règles sont un extrait de openvpn-outils , présenté dans Installer et installer OpenVPN sur Debian , un script de gestion OpenVPN et sur la manière dont j'ai écrit.
Assurez-vous également d'avoir un serveur DNS accessible à partir de vos clients VPN. Une réponse simple est Opendns (8.8.8.8). Une solution plus complexe, mais peut-être meilleure consiste à installer Lié sur le serveur (c'est la solution utilisée par OpenVPN-Tools).
openVPN-Tools peut vous intéresser car il fournit des exportations de configuration de clients pour divers systèmes et automatisez la configuration des nouveaux réseaux VPN.
Modifier pour OpenVPN 2.x Server et 1.5 Client
Voir: OpenVPN publie des notes .
Pour obtenir OpenVPN 2.0 pour parler avec les versions 1.5/1.6, mettez ceci dans le fichier de configuration 1.x:
tun-mtu 1500
tun-mtu-extra 32
mssfix 1450
key-method 2
Pour l'utilisation TLS, la méthode Key-Method 2 est maintenant la valeur par défaut.
Dans votre situation, vous devriez essayer d'utiliser un routage standard au lieu d'utiliser NAT (entre le réseau interne et le réseau OpenVPN). NAT devrait être votre dernière option.
Le "routeur de bord" (probablement votre CPE) (Bewteen votre réseau interne et le reste d'Internet) doivent envoyer les paquets pour les nœuds VPN (en 192.168.3.0/24) sur le serveur ouvert. Vous devez ajouter un itinéraire comme celui-ci dans le routeur de bord/CPE:
# This is the Linux command, find the equivalent for your router:
ip route add 192.168.3.0/24 via 192.168.2.111
Maintenant, ce routeur peut être un routeur XDSL + FAI-FAI-FAI-FAIS, afin que vous ne puissiez peut-être pas faire cela.
Si vous ne pouvez pas faire cela (vous ne pouvez pas ajouter de itinéraires sur votre routeur) et si votre routeur de bord pense que votre Nerwork interne est de 192.168.0.0/16 (ou du moins contient du 192.168.3.0/34), vous pouvez configurer un proxy ARP dans Eth0 pour le Nœuds VPN dans le réseau principal:
echo 1 > /proc/sys/net/ipv4/conf/$xx/proxy_arp
avec x = ETH0, x = tun0, x = Tout (je ne sais pas vraiment dans quelle interface vous devez définir cette option).
Ces idées sont que votre serveur OpenVPN répondra aux demandes d'ARP sur l'ETH0 NetRwork pour les nœuds du VPN. Il ne fonctionnera que votre routeur pense que 192.168.30/24 se trouve dans le réseau interne: Autretrise, il n'enverra pas de demandes ARP sur le réseau interne.