La Fibre
Datacenter et équipements réseaux => Routeurs => 
Routeur => Discussion démarrée par: sbo le 27 février 2019 à 08:07:58
-
Bonjour,
N'arrivant pas à faire transiter le flux de certaines destinations dans le tunnel VPN, je me permets de faire appel à votre expertise.
Le contexte, sur l'USG mais valable aussi sur un ER, je désire que certains flux sur des adresses ou réseaux destinations (adresses publiques), le flux de ces destinations soit routé dans le tunnel VPN OpenVPN client définit dans le router.
Hélas aujourd'hui seul le VPN PPTP est intégré nativement dans l'USG. J'ai vu sur le forum officiel d'Ubiquiti qu'il y avait pas mal de demandes d'ajouter openvpn client, mais pas encore pris en compte par le constructeur.
Le client Openvpn est configuré et fonctionnel sur l'USG et l'interface vtun0 est bien up.
Il y a ici et sur le forum ubiquiti quelques tuto pour gérer en fonction de l'adresse source, mais rien avec les adresses destination. Ma question est est-ce un problème de compréhension ou alors mon besoin n'est pas faisable par adresses destination.
Voilà la configuration essayée, mais qui fonctionne partiellement.
Coté interface :
Interface IP Address S/L Description
--------- ---------- --- -----------
eth0 - u/u WAN
eth0.832 81.249.x.x/21 u/u WAN
eth1 192.168.0.254/24 u/u LAN
eth2 - A/D
lo 127.0.0.1/8 u/u
::1/128
vtun0 10.115.212.17/23 u/u
ta table de routage :
show ip route
Codes: K - kernel route, C - connected, S - static, R - RIP, O - OSPF,
I - ISIS, B - BGP, > - selected route, * - FIB route
S>* 0.0.0.0/0 [1/0] via 81.249.208.1, eth0.832
C>* 10.115.212.0/23 is directly connected, vtun0
C>* 81.249.x.0/21 is directly connected, eth0.832
C>* 127.0.0.0/8 is directly connected, lo
C>* 192.168.0.0/24 is directly connected, eth1
Là aucune route pour faire transiter le flux vers une destination particulière dans le vpn.
ajout de la route :
set protocols static interface-route x.x.x.x/32 next-hop-interface vtun0
S>* X.X.X.X/32 [1/0] is directly connected, vtun0le traceroute à partir du router fait désormais passer le flux dans le VPN.
Maintenant il reste à gérer le routage depuis un poste client et là cela coince.
J'ai essayé la configuration suivante en me basant sur les tuto parlant de routage en fonction des adresses/réseaux sources en l'adaptant en destination :
et protocols static table 1 interface-route 0.0.0.0/0 next-hop-interface vtun0
set firewall modify DESTINATION_ROUTE rule 10 description "Route trafic to VPN from x.x.x"
set firewall modify DESTINATION_ROUTE rule 10 destination address x.x.x.x
et
set firewall modify DESTINATION_ROUTE rule 10 modify table 1
set protocols static table 1 interface-route x.x.x.x/32 next-hop-interface vtun0
set interfaces ethernet eth1 firewall out modify DESTINATION_ROUTE
set service nat rule 5004 description "masq to vpn vtun0"
set service nat rule 5004 destination address 0.0.0.0/0
set service nat rule 5004 outbound-interface vtun0
set service nat rule 5004 type masquerade
Je pense avoir mal compris le principe, car cela fonctionne sur la première IP destination, mais pour un groupe d'IP ou l'ajout d'une nouvelle IP dans la règle, le routage ne fonctionne pas.
Merci par avance pour les pistes et toutes explications pour mieux comprendre le fonctionnement de ce type de routage.
@zoc je ne sais pas si tu as ce type de compétence ou d'autres.
-
Salut,
Tu peux créer des groupes d'IP dans ton USG en utilisant la commande :
set firewall group address-group MONGROUPE address X.X.X.Xà répéter pour chaque IP.
Et dans cette commande :
set protocols static table 1 interface-route 0.0.0.0/0 next-hop-interface vtun0
set firewall modify DESTINATION_ROUTE rule 10 description "Route trafic to VPN from x.x.x"
set firewall modify DESTINATION_ROUTE rule 10 destination address x.x.x.x
Remplace destination address par destination group MONGROUPE, donc :
set protocols static table 1 interface-route 0.0.0.0/0 next-hop-interface vtun0
set firewall modify DESTINATION_ROUTE rule 10 description "Route trafic to VPN from x.x.x"
set firewall modify DESTINATION_ROUTE rule 10 destination group MONGROUPE
-
set protocols static table 1 interface-route 0.0.0.0/0 next-hop-interface vtun0
Là tu dis que la route par défaut pour la table 1 est tunnel. Ok.
set protocols static table 1 interface-route x.x.x.x/32 next-hop-interface vtun0
Là tu dis que la route pour x.x.x.x/32, toujours dans la table 1, est le tunnel. Inutile, la route par défaut le fait déjà.
set interfaces ethernet eth1 firewall out modify DESTINATION_ROUTE
Là tu dis au routeur d'appliquer les règles modify sur les paquets qui sortent par l'interface eth1. Je ne suis pas spécialiste du PBR mais pour moi cette règle devrait être en "in" et pas "out".
Pour le reste je n'ai pas trop de commentaires.
Après, ce qui est dommage, c'est le double NAT (celui quand tu sors par vtun0 + celui quand tu sors à l'autre bout du VPN), mais selon si tu maitrises ou non la configuration du VPN à l'autre bout tu peux ne pas avoir vraiment le choix.
-
Tu peux créer des groupes d'IP dans ton USG en utilisant la commande :
Très juste. Ca ne va cependant pas régler son problème actuel.
-
Là tu dis au routeur d'appliquer les règles modify sur les paquets qui sortent par l'interface eth1. Je ne suis pas spécialiste du PBR mais pour moi cette règle devrait être en "in" et pas "out".
Pour le reste je n'ai pas trop de commentaires.
Après, ce qui est dommage, c'est le double NAT (celui quand tu sors par vtun0 + celui quand tu sors à l'autre bout du VPN), mais selon si tu maitrises ou non la configuration du VPN à l'autre bout tu peux ne pas avoir vraiment le choix.
Oui le in c'est une adaptation du tuto qui présentait la solution avec le routage en adresses IP source.
Il est fort probable que mon adaptation soit fausse :D
Pour ton observation sur le double NAT, j'avoue être perdu.
J'avais essayé @elliotvr le groupe, mais comme le problème semble être ailleurs dans ma configuration cela ne résoud pas la cause. Mais lorsque la configuration sera fonctionnelle (si c'est possible) j'utiliserais la notion de group beaucoup plus souple pour ajouter des hosts et simplifier la configuration.
Je vais attendre si quelqu'un a déjà fait ce type de configuration.
-
T'as essayé de changer le "out" en "in" du coup ?
-
T'as essayé de changer le "out" en "in" du coup ?
Je vais essayer mais après ne devrais-je pas aussi changer l'interface
L'eth1 correspond a mon LAN
ce que j'avais interprété de la commande suivante, c'est applique les règles de DESTINATION_ROUTE sur l'interface eth1 (donc mon LAN) pour les flux sortant correspond aux règles.
set interfaces ethernet eth1 firewall out modify DESTINATION_ROUTE
si je remplace par
set interfaces ethernet eth1 firewall in modify DESTINATION_ROUTE
Cela devrait signifier applique la règle DESTINATION_ROUTE pour les flux entrant. Et là je pige pas le principe.
Ou alors il faut que je change l'interface entrante et dans ce cas cela serait vtun0.
Je vais essayer néanmoins, mais si cela fonctionne, c'est que j'ai rien compris à ce paramètre :D
-
"in" signifie ce qui rentre sur l'interface.
Là le but est de sélectionner la table de routage "1" pour les paquets qui proviennent du LAN et destinés à sortir par le VPN. La modification doit donc se faire en "in" sur l'interface du LAN.
-
C'est très bien expliqué ici (en Anglais) :
https://help.ubnt.com/hc/en-us/articles/115003173168-UniFi-USG-Firewall-Introduction-to-Firewall-Rules#3
-
Je viens d'essayer avec le In, cela fonctionne toujours sur la première règle. Mais je penses que c'est dut au fait qu'il me reste cela :
set protocols static interface-route x.x.x.x/32 next-hop-interface vtun0
Si je supprime cette route, le router repasse sur la route par défaut a savoir sur l'interface eth0.832.
quand on fait un show ip route, il ne nous montre pas les routes pour les tables complèmentaire (table 1 dans mon cas).
J'ai donc l'impression que si je route sans utiliser la table cela fonctionne, mais je ne vais pas mettre deux routes 0.0.0.0/0 sur deux interfaces :)
Bon déjà c'est plus clair, j'ai un problème de prise en compte de la table 1, mais après comment le diagnotiquer ca c'est une autre histoire
-
quand on fait un show ip route, il ne nous montre pas les routes pour les tables complèmentaire (table 1 dans mon cas).
show ip route table 1 ;)
-
:D :D :D :D
set protocols static table 1 interface-route 0.0.0.0/0 next-hop-interface vtun0
The specified configuration node already exists
show ip route table 1
default dev vtun0 scope link
mais quand je fais un traceroute à partir du router vers un des host dans le groupe qui doit appliquer la table 1 cela ne passe pas par la bonne interface, pire le même traceroute à partir d'un client du LAN lui ne trouve même plus la route après avoir supprimer le routage hors de la table 1
J'en conclue que la règle qui pourtant indique d'utiliser les règles DESTINATION_ROUTE
set firewall modify DESTINATION_ROUTE rule 10 modify table 1ou que DESTINATION_ROUTE est incorrect (le in/out).
-
show ip route table 1
default dev vtun0 scope link
Je pense que le problème c'est le "scope link". Il n'est pas présent dans la table de routage principale (show ip route table main) pour la route par défaut.
mais quand je fais un traceroute à partir du router vers un des host dans le groupe qui doit appliquer la table 1
Normal puisque rien sur le router ne dit d'utiliser la table 1 (pas de règle modify) pour les paquets locaux.
-
Normal puisque rien sur le router ne dit d'utiliser la table 1 (pas de règle modify) pour les paquets locaux.
A mince mes tests sur le router avant d'effecteur le test sur un poste ne servait a rien. Je pensais que le router appliquerait les mêmes règles
Pour la table main
show ip route table main
default via 81.249.208.1 dev eth0.832 proto zebra
10.115.212.0/23 dev vtun0 proto kernel scope link src 10.115.212.17
81.249.x.0/21 dev eth0.832 proto kernel scope link src 81.249.214.165
127.0.0.0/8 dev lo proto kernel scope link src 127.0.0.1
192.168.0.0/24 dev eth1 proto kernel scope link src 192.168.0.254
La main c'est celle utiliser par et pour le router ?
-
La table "main" (254) c'est la table utilisée par défaut par le routeur en l'absence d'une règle modify. Donc clairement pour un paquet qui part du routeur c'est la table main qui est utilisée.
Il semblerait qu'il ne soit pas possible d'ajouter une route vers 0.0.0.0/0 de scope global dans les autres tables (en tout cas à partir du fichier de config EdgeOS). Du coup, la table 1 n'a plus vraiment d'intérêt, autant rajouter une route statique par destination dans la table de routage principale: Elle s'appliquera au traffic local et aussi au traffic routé.
Après, ce que tu fais n'est pas très différent de ce qui est décrit ici: https://help.ubnt.com/hc/en-us/articles/204952274-EdgeRouter-Policy-Based-Routing (et ils suggèrent une route par défaut dans chaque table) donc ça devrait marcher...
-
La table "main" (254) c'est la table utilisée par défaut par le routeur en l'absence d'une règle modify. Donc clairement pour un paquet qui part du routeur c'est la table main qui est utilisée.
Il semblerait qu'il ne soit pas possible d'ajouter une route vers 0.0.0.0/0 de scope global dans les autres tables (en tout cas à partir du fichier de config EdgeOS). Du coup, la table 1 n'a plus vraiment d'intérêt, autant rajouter une route statique par destination dans la table de routage principale: Elle s'appliquera au traffic local et aussi au traffic routé.
Ok donc simplement une route par dest dans la table globale. Je vais faire le ménage dans toutes les règles existantes avant car là les clients ne trouve pas. Je dois avoir une règle qui perturbe.