Ce que bypass-dhcp ajoute réellement à un plan de routes OpenVPN

Un profil qui porte redirect-gateway def1 bypass-dhcp combine un remplacement de la route IPv4 par défaut avec une seule exception étroite. Les gens lisent le dernier mot et attendent une solution générale pour les connexions mobiles, puis passent un après-midi sur une théorie DHCP que l'indicateur n'a jamais soutenue. Chaque partie fait une chose, et l'exception est bien plus petite que sa réputation.

Séparez les indicateurs avant d'attribuer une panne propre à la connexion mobile à l'attribution d'adresses. Les deux moitiés de cette chaîne n'ont rien à voir l'une avec l'autre.

Deux indicateurs, deux tâches sans rapport

Avec def1, le client ajoute deux demi-routes IPv4 par défaut au lieu de remplacer la route par défaut déjà présente. 0.0.0.0/1 couvre la moitié basse de l'espace d'adressage et 128.0.0.0/1 la moitié haute, si bien qu'ensemble elles atteignent toute destination tout en restant chacune plus précise que 0.0.0.0/0. La route par défaut d'origine reste donc dans la table sans gagner ces recherches, ce qui garde l'ancienne passerelle joignable pour tout ce que le client route explicitement. Cela laisse aussi deux routes par défaut qui se chevauchent dans la table, et c'est pourquoi un vidage des routes peut sembler plus étrange que ne le suggère le profil.

bypass-dhcp est séparé et ne touche pas du tout la route par défaut. Le manuel d'OpenVPN 2.6 le décrit comme l'ajout d'une route directe vers un serveur DHCP qui n'est pas sur le sous-réseau local, afin que le trafic de bail sorte hors du tunnel, et note que ce comportement est implémenté sur les clients Windows et pourrait ne pas être disponible ailleurs.

La raison de son existence est mécanique. Une fois que les demi-routes par défaut capturent le trafic sortant, un renouvellement DHCP visant un serveur du réseau physique serait routé dans le tunnel, sauf si quelque chose fixe cette adresse à l'interface réelle. L'indicateur la fixe.

À quoi l'exception est réellement limitée

Un tableau illustratif après une connexion réussie montre la forme : deux demi-routes par défaut via le tunnel et une route d'hôte pour le serveur DHCP via la passerelle physique. Lisez-le comme une forme, pas comme vos propres adresses.

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

Cette troisième ligne nomme une seule destination. Ce n'est pas un réglage du résolveur, ni une autorisation générale pour le réseau local, ni une règle de sortie sur le serveur. Un téléphone sur un réseau mobile peut ne pas avoir de serveur DHCP que le client puisse identifier de cette façon, et c'est pourquoi l'indicateur n'y change rien.

Vérifiez ce que le client a réellement installé

Distinguez une option écrite dans un profil, une option proposée par le serveur et une route que le propriétaire de la connexion a réellement appliquée. Un client qui refuse un indicateur non pris en charge peut conserver le reste de la configuration, si bien que le tunnel monte et que l'exception est simplement absente. Lisez le journal du client lui-même et la table de routage obtenue plutôt que de supposer que la ligne du fichier a pris effet. Trois de ces choses peuvent être vraies en même temps, et seule la dernière change où vont réellement les paquets.

Gardez la route vers le point de terminaison VPN utilisable en même temps. Cette exception de point de terminaison est une exigence différente de l'exception DHCP, et sans elle le tunnel peut capturer le transport qui le maintient.

Pour une destination d'application, examinez la résolution effective dans le contexte où elle échoue. Des routes locales plus précises, le routage par politique et des exclusions par application changent toutes la réponse, donc la présence de deux demi-routes par défaut n'est pas un inventaire de chaque flux.

Le reste du chemin n'est pas dans cet indicateur

Le serveur a toujours besoin de l'autorisation de transférer le trafic internet du client et d'un dispositif de sortie capable de le renvoyer. Aucune route côté client ne crée un transfert ni une traduction de source manquants sur le serveur, et aucun indicateur ne remplace un chemin de retour fonctionnel.

La résolution de noms et IPv6 ont chacune besoin de leur propre politique. Un remplacement IPv4 ne pointe ni le résolveur vers un serveur du côté du tunnel ni n'établit de couverture IPv6, et un client qui ne redirige que v4 laisse intact un chemin v6.

Comparez une requête inoffensive approuvée sur un chemin d'accès qui fonctionne et sur un autre qui échoue, le profil et la destination restant fixes. Notez si la différence se situe dans la résolution de noms, l'établissement du tunnel, la sélection de route ou le trafic transféré, et conservez la réponse avec le profil. C'est ce relevé qui empêche la personne suivante de blâmer DHCP pour un problème qu'il ne peut pas atteindre.