Accès au LAN via OpenVPN cassé ? Vérifiez zones, routes et chemin de retour

Le tunnel signale une connexion réussie, la page du routeur lui-même se charge, et le lecteur réseau vers une machine derrière lui expire encore. Rien dans cette combinaison n'est contradictoire : le routeur répond en tant que lui-même, et atteindre quoi que ce soit derrière lui est une autre décision prise ailleurs. Faites les vérifications ci-dessous dans l'ordre et arrêtez-vous au premier échec, car chacune repose sur la précédente. Quand les quatre passent, la panne se situe au-dessus du tunnel, pas dedans.

Quel filtre voit un paquet vers le LAN

Un paquet adressé au routeur est consommé localement ; un paquet adressé à un hôte derrière lui doit être transféré, et les pare-feu jugent ces deux cas séparément. L'autorisation d'atteindre le routeur ne dit donc rien de l'autorisation de le traverser. Un firmware qui cache ses jeux de règles implémente quand même les deux, généralement sous forme de sélecteur proposant le LAN, Internet ou les deux. Si le sélecteur omet le LAN, aucune vérification ultérieure ne comptera.

OpenWrt rend cette séparation inspectable, et la distinction vaut une lecture. La zone qui termine le tunnel a besoin d'une règle de transfert vers la zone LAN, alors qu'une règle d'entrée ne régit que les services du routeur lui-même. Une page d'administration fonctionnelle à côté d'un LAN mort est le résultat ordinaire de cette règle de transfert manquante.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Regardez la cible de transfert de la zone qui porte le tunnel : accept est ce dont l'échelle a besoin, et reject explique chaque expiration ci-dessous. Deux réglages voisins produisent le même symptôme, alors écartez-les pendant que vous êtes là. L'isolation sans fil cache les hôtes filaires aux clients sans fil, et un routeur qui traite les hôtes LAN inactifs comme hors ligne peut jeter les réponses même après que le transfert fonctionne.

Pourquoi un tunnel divisé a besoin du préfixe poussé

Un client qui envoie tout le trafic par le tunnel détient déjà le préfixe LAN via sa route par défaut, donc il n'y a rien à ajouter. Le tunnel divisé est le cas qui exige le préfixe énoncé explicitement, car rien d'autre dans la configuration ne le mentionne. Ajoutez la directive à la configuration du serveur et rechargez le service.

push "route 192.168.50.0 255.255.255.0"

Les profils contenant route-nopull ignorent les routes poussées, donc le même préfixe appartient au fichier client à la place. Dans tous les cas, confirmez que l'entrée est arrivée au lieu de le supposer, car un remplacement silencieux ressemble exactement à un problème de pare-feu.

ip route show | grep 192.168.50

Un pair de site à site demande plus qu'un push. Le serveur doit apprendre quels préfixes se trouvent derrière ce pair, ce que fait une ligne iroute dans son fichier client-config-dir, et sa propre table a besoin d'une route correspondante vers le tunnel.

La réponse a besoin d'une adresse qu'elle peut atteindre

Transférer la requête n'est que la moitié d'un échange, car l'hôte du LAN doit répondre à une adresse du pool du tunnel. Les petits routeurs arrangent cela généralement en traduisant la source sur la zone du tunnel, si bien que la réponse est adressée au routeur et ne demande aucune configuration ailleurs. Retirez cette traduction et l'hôte a besoin de sa propre route vers le pool, qu'il obtient gratuitement quand le routeur est sa passerelle par défaut. Un hôte avec une adresse fixée à la main et une autre passerelle répond par cette passerelle, et le client voit une session s'ouvrir puis caler.

tcpdump -ni tun0 host 192.168.50.20

Lancez cela sur le routeur pendant que le client répète sa requête, et lisez la destination de la réponse plutôt que la requête. Une réponse adressée au pool signifie que le chemin de retour fonctionne et que la panne est plus loin. Aucune réponse signifie que l'hôte n'a jamais accepté le paquet, ce qui vous renvoie au jeu de règles.

Une échelle qui se termine au bon endroit

Quatre vérifications localisent la couche, et chacune est une seule commande plutôt qu'un jugement. Exécutez-les dans l'ordre et arrêtez-vous au premier échec. L'ordre compte plus que les commandes, car une étape ultérieure réussie cache la raison de l'échec d'une précédente.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Les noms vont à la fin de l'échelle, jamais au début. Un partage qui répond comme 192.168.50.20 mais pas comme nas.local pointe vers la résolution ou vers un suffixe de recherche, et les modifications du pare-feu ne peuvent changer ni l'un ni l'autre.

Notez la première étape échouée, puis accordez aux ports de service leur propre passe, car un écouteur et une autorisation d'hôte sont des exigences distinctes. Le partage de fichiers, le bureau à distance et les flux de caméra ont besoin des deux, et un pare-feu d'hôte qui fait confiance au sous-réseau LAN mais pas au pool du tunnel écarte le client alors que ping réussit encore. Quand toutes les vérifications passent et que l'application échoue toujours, la panne est au-dessus du tunnel : un service lié à une interface, ou un proxy configuré sur le client.