MULTI: mauvaise adresse source du client - des solutions ponctuelles?

Configuration: J'ai une configuration client / serveur openvpn (fichiers de configuration en bas), et je reçois le fameux MULTI: bad source address from client [192.168.x.x], packet droppedmessage sur le serveur. Le serveur a une adresse IP publique, tandis que le client est derrière NAT.

Lacunes des solutions précédemment proposées: La client-config-dirdéfinition dans la configuration du serveur est actuellement vide. Les articles précédents (ici et dans les forums de support openvpn) suggèrent d'ajouter soit un fichier nommé DEFAULTavec les règles appropriées dans client-config-dir, soit ajouter un fichier par utilisateur avec ces règles pour résoudre le problème.

Cependant, cela ne semble pas être une solution à long terme, car ces règles sont spécifiques à l'emplacement du client. Je peux donc ajouter une règle pour autoriser les clients 192.168.x.0à se connecter. Mais s'ils se connectent à partir d'un autre réseau qui utilise à la place 192.168.y.0pour NAT, une nouvelle règle sera requise.

Des questions:

• Les règles requises peuvent-elles être écrites de manière générique / ponctuelle?
• Quelqu'un peut-il expliquer pourquoi ce problème se produit en premier lieu?

Configuration du serveur:

port 1234
proto tcp
dev tun

ca ca.crt
cert openvpn.crt
key openvpn.key
dh dh2048.pem

server 10.78.96.0 255.255.255.0
keepalive 10 120
comp-lzo
cipher CAMELLIA-128-CBC

user nobody
group nogroup  
persist-key
persist-tun
client-cert-not-required
plugin /usr/lib/openvpn/openvpn-auth-pam.so login

status openvpn-status.log

push "redirect-gateway def1"
push "remote-gateway 1.2.3.4"
push "dhcp-option DNS 8.8.8.8"

client-config-dir ccd
verb 4

Configuration client:

ca ca.crt
client
dev tun
proto tcp
remote 1.2.3.4 1234

auth-user-pass
script-security 2
keepalive 5 60
topology subnet
resolv-retry infinite
nobind
persist-key
persist-tun
ns-cert-type server
cipher CAMELLIA-128-CBC
comp-lzo
verb 4

Vous avez demandé: " Quelqu'un peut-il expliquer pourquoi ce problème se produit en premier lieu? "

Sur la base de ce qui est rapporté dans la FAQ officielle d'OpenVPN, je parie que cela est dû à un problème de routage dans le moteur OpenVPN.

Pour mieux clarifier le scénario, je me réfère au schéma suivant:

Içi vous pouvez voir:

• un "serveur" OpenVPN connecté au réseau interne HEADQUARTER (10.0.1.0/24)
• un "client" OpenVPN s'exécutant sur un site distant et connecté au réseau distant 192.168.1.0/24

Aussi

• nous supposons que le tunnel OpenVPN est établi et:
  • Le "serveur" OpenVPN est accessible via sa propre interface tun , avec l'adresse 10.10.0.1. De plus, l'adresse P2P, utilisée par l'interface tun est 10.10.0.2 ( c'est important pour une discussion ultérieure, nous allons donc le souligner )
  • OpenVPN "client" a une interface tun avec IP 10.10.0.2

Supposons maintenant que:

• le "Client" OpenVPN a redéfini sa passerelle par défaut, afin de rediriger dans le tunnel tout le trafic IP sortant;
• le "Client" OpenVPN a activé IP_FORWARDING et, en tant que tel, peut router les paquets provenant de son LAN interne (192.168.1.0/24) ( j'insiste sur ce point, car il est essentiel pour notre discussion ).

Avec un tel scénario en place, vérifions en détail ce qui se passe lorsque R_PC1 (192.168.1.2) envoie un paquet, comme une demande d'écho, à L_PC1 (10.0.1.2):

1. après avoir quitté R_PC1 NIC, le paquet atteint le client OpenVPN;
2. Client OpenVPN (qui est configuré pour agir comme un routeur commun), acheminez-le en fonction de sa table de routage. Comme sa passerelle par défaut est le tunnel, il envoie le paquet au tunnel;
3. Le paquet atteint l'interface tun du serveur OpenVPN. OpenVPN le "verra" et, comme il (serveur OpenVPN) sait que 10.0.1.2 est une adresse appartenant à son sous-réseau LAN, il "transfère" le paquet, du TUN au LAN;
4. Le paquet atteint L_PC1.

Alors tout va bien...

Voyons maintenant ce qui se passe avec l'écho-réponse que L_PC1 répond à R_PC1.

5. echo-reply quitte la carte réseau L_PC1 et atteint l'interface LAN du serveur OpenVPN (10.0.1.1);

Maintenant, si nous voulons qu'OpenVPN Server puisse atteindre le site distant, nous devons définir le routage avec une "route statique". Quelque chose comme:

route add -net 192.168.1.0 netmask 255.255.255.0 gw 10.10.0.2

Veuillez noter l'adresse P2P utilisée comme passerelle .

Ces routes statiques fonctionneront au niveau du système d'exploitation. En d'autres termes, il est nécessaire que le système d'exploitation achemine correctement le paquet. Cela signifie quelque chose comme: "S'il vous plaît, tout le trafic adressé au sous-réseau 192.168.1.0/24 doit être transmis au moteur OpenVPN, avec lequel le système d'exploitation est capable de parler via l'adresse P2P". Grâce à cette route statique, maintenant ...

6. le paquet quitte le contexte de routage du système d'exploitation et atteint OpenVPN. L'instance OpenVPN s'exécutant sur le serveur OpenVPN. Donc, à ce stade, le système d'exploitation n'a plus rien à faire et tout le routage (au sein du VPN) est laissé au logiciel serveur OpenVPN.

Donc, maintenant, le problème est: comment, le logiciel serveur openvpn, pourra-t-il décider de l'itinéraire d'un paquet, avec SRC_IP 10.0.1.2 et DST_IP 192.168.1.2 ?

Veuillez noter que, basé sur la configuration du serveur OpenVPN, il ne sait rien du réseau 192.168.1.0/24, ni de l'hôte 192.168.1.2. Ce n'est pas un client connecté. Ce n'est pas un client local. Et donc? OpenVPN sait également que ce n'est pas le "OS-Router", donc il ne veut pas vraiment (et peut ....) renvoyer le paquet à la passerelle locale. Donc, la seule option, ici, est de déclencher une erreur. Exactement l'erreur que vous rencontrez

Pour le dire avec le langage de la FAQ: " ... il ne sait pas comment acheminer le paquet vers cette machine, donc il laisse tomber le paquet ... ".

Comment pouvons-nous résoudre le problème?

Comme vous pouvez le voir dans la documentation officielle , l'option iroute sert exactement à notre portée:

--iroute network [netmask]
Generate an internal route to a specific client. The netmask 
parameter, if omitted, defaults to 255.255.255.255.
This directive can be used to route a fixed subnet from the server 
to a particular client, regardless of where the client is 
connecting from. Remember that you must also add the route to the 
system routing table as well (such as by using the --route 
directive). The reason why two routes are needed is that the 
--route directive routes the packet from the kernel to OpenVPN. 
Once in OpenVPN, the --iroute directive routes to the specific 
client.

Vous avez donc besoin d'un:

--iroute 192.168.1.0 255.255.255.0

à appliquer (au serveur) lorsque votre client OpenVPN se connecte, par exemple via un fichier de configuration ad-hoc défini sur le serveur (client-config-dir, etc.).

Si vous vous demandez pourquoi ce problème ne se produit pas à l'étape 2) ci-dessus, je comprends qu'OpenVPN Client sait comment l'acheminer, car il sait que le tunnel VPN est une passerelle par défaut.

La même chose ne peut pas être faite sur OpenVPN Server, car là, la passerelle par défaut n'est généralement pas remplacée. En outre, considérez que vous pourriez avoir un seul serveur OpenVPN avec beaucoup de clients OpenVPN: chaque client sait comment atteindre le serveur mais ... comment le serveur peut-il décider quel client fait office de passerelle pour un sous-réseau inconnu?

Quant à votre première question ( les règles requises peuvent-elles être écrites de manière générique / ponctuelle? ), Je suis désolé mais je ne reçois pas votre problème. Pouvez-vous reformuler en fournissant plus de détails?

J'ai eu un problème qui semble similaire, mais je ne sais pas si c'est le même que votre problème. J'essayais d'envoyer une requête ping d'un client openvpn à un ordinateur dans le réseau local du serveur openvpn (acheminé dans la configuration du serveur), sans obtenir de réponse et je pouvais voir le message "mauvaise adresse source" dans le journal openvpn du serveur.

Pour le résoudre, j'ai dû faire 2 choses:

1. Activez le transfert IP sur le serveur.
2. Ajoutez une route pour le sous-réseau vpn sur la passerelle du serveur, car la passerelle pour le réseau local du serveur dans mon cas n'est pas le serveur lui-même, mais un routeur. L'ordinateur cinglé essayait de répondre via la passerelle, qui ne savait pas quoi faire pour le sous-réseau vpn. J'ai donc ajouté une route statique dans le routeur en utilisant le sous-réseau vpn pour la destination, et l'ip du serveur openvpn comme passerelle pour cela.

Cela m'a arrangé.