Le setup désiré : on est sur un réseau nazi (tous les ports sont bloqués en IN/OUT sauf tcp/udp/53/80/443 en sortie, tcp/25 est redirigé en sortie, ...) sur lequel nous n'avons pas la main (sinon il ne serait pas nazi, CQFD :D ). On veut installer notre propre réseau, et, sur l'unique routeur de sortie de notre réseau cloisonné mais relié au réseau nazi, on veut installer un client OpenVPN qui acheminera tout le trafic de notre réseau indépendant dans un réseau neutre.
Le setup en lui-même est simple mais, tous les 5 jours environ (durée variable, dépend de la durée du bail DHCP ;) ), ça s'écroule.
Le log OpenVPN indique « RESOLVE: Cannot resolve host address: <nom_serveur>: [TRY_AGAIN] A temporary error occurred on an authoritative name server. » en boucle. Pourtant, au moins un des récursifs DNS utilisés par la machine (/etc/resolv.conf) dispose d'une route plus spécifique qui contourne justement le VPN pour éviter ce problème.
Dans le cas où le récursif DNS serait en cause, ne pas céder à la tentation de remplacer « remote <nom_serveur> » par « remote <IP_serveur> » dans la conf' d'OpenVPN : le DNS permet la flexibilité : les admins du serveur OpenVPN peuvent ainsi changer les adresses IP du serveur (motifs : panne, problème de routage, renew d'allocation, ...) sans avoir à avertir tous les utilisateurs, ce qui serait long, fastidieux et n'empêcherait pas un downtime prolongé le temps que l'information soit diffusée et que l'utilisateur effectue le changement dans la configuration !
Dans notre cas, un grep dhclient « /var/log/daemon.log.1 | less » est très révélateur :
Dec 20 20:36:12 vpn dhclient: Internet Systems Consortium DHCP Client 4.2.2
Dec 20 20:36:12 vpn dhclient: Copyright 2004-2011 Internet Systems Consortium.
Dec 20 20:36:12 vpn dhclient: All rights reserved.
Dec 20 20:36:12 vpn dhclient: For info, please visit
https://www.isc.org/software/dhcp/
Dec 20 20:36:12 vpn dhclient:
Dec 20 20:36:12 vpn dhclient: Listening on LPF/eth0/00:1b:fc:c1:cc:53
Dec 20 20:36:12 vpn dhclient: Sending on LPF/eth0/00:1b:fc:c1:cc:53
Dec 20 20:36:12 vpn dhclient: Sending on Socket/fallback
Dec 20 20:36:12 vpn dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Dec 20 20:36:20 vpn dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 14
Dec 20 20:36:20 vpn dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Dec 20 20:36:20 vpn dhclient: DHCPOFFER from 172.16.112.254
Dec 20 20:36:20 vpn dhclient: DHCPACK from 172.16.112.254
Dec 20 20:36:20 vpn dhclient: bound to 172.16.121.170 -- renewal in 300182 seconds.
Dec 25 14:11:00 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Dec 25 14:11:08 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Dec 25 14:11:19 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Dec 25 14:11:31 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
[...]
Dec 26 23:16:20 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Dec 26 23:16:35 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Dec 26 23:16:51 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Dec 26 23:17:00 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
[...]
Dec 28 06:24:21 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Dec 28 06:24:35 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Dec 28 06:24:54 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Dec 28 06:25:06 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
[...]
Jan 2 20:24:05 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Jan 2 20:24:19 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Jan 2 20:24:31 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
Jan 2 20:24:48 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67
[...]
Le client DHCP n'arrive pas à renouveler son allocation auprès du serveur DHCP qui la lui a attribuée. On remarque que la demande est en unicast. On remarque aussi que l'adresse IP change le long du log : « Dec 20 20:36:20 vpn dhclient: DHCPOFFER from 172.16.112.254 » - « Jan 2 20:24:05 vpn dhclient: DHCPREQUEST on eth0 to 172.16.128.1 port 67 ».
Étrange. Regardons notre bail DHCP :
cat /var/lib/dhcp/dhclient.eth0.leases
lease {
interface "eth0";
fixed-address 172.16.123.45;
option subnet-mask 255.255.240.0;
option routers 172.16.112.254;
option dhcp-lease-time 691200;
option dhcp-message-type 5;
option domain-name-servers 172.16.128.2,172.16.128.1;
option dhcp-server-identifier 172.16.128.1;
option dhcp-renewal-time 345600;
option dhcp-rebinding-time 604800;
option domain-name "<censure>";
renew 2 2015/01/13 19:24:53;
rebind 5 2015/01/16 21:39:57;
expire 6 2015/01/17 21:39:57;
}
[ Les plus observateurs remarqueront que ce bail n'est pas celui qui correspond au log précédent. Je n'ai pas conservé l'ancien bail mais je voulais quand même illustrer ce shaarli. ]
« option dhcp-server-identifier 172.16.128.1; » : le serveur DHCP est en dehors du réseau sur lequel nous sommes. Il y a utilisation de la fonctionnalité relai DHCP. En temps normal, cela ne pose pas de problème : l'intégralité du trafic, y compris les messages DHCP unicast, sont envoyés au routeur, 172.16.112.254 dans notre cas, qui sait joindre le serveur DHCP. Sauf qu'avec un VPN dans lequel on route tout sauf le réseau local, les messages DHCP unicast, qui ne sont pas à destination du réseau local, sont envoyés dans le VPN. L'IP du serveur DHCP étant RFC1918, les paquets seront jetés par le FAI.
Solution : ajouter une route vers le serveur DHCP qui contourne le VPN. Cela se fait dans la configuration du client OpenVPN. Dans notre cas : « route 172.16.128.1 255.255.255.255 172.16.112.254 ».
Ce que je ne m'explique pas : à la fin du bail (691200 secondes soit 8 jours), le client DHCP ne devrait plus être en phase de renew unicast mais devrait redemander une adresse (et les autres paramètres) en broadcast. Or, ce n'est pas ce que nous constatons dans les logs. Ça n'empêcherait pas une coupure du service mais ça serait logique.