La Fibre
Datacenter et équipements réseaux => Routeurs => 
Ubiquiti => Discussion démarrée par: boho le 26 novembre 2016 à 10:57:42
-
Bonjour a tous,
J'utilise un ERL et en parallèle un accès VPN typé "privacy" à partir d'un poste client.
Voulant élargir l'usage à plus de postes, je me dis que ce serait plus malin de gérer la connexion à partir du routeur.
Le prestataire que j'utilise est BlackVPN et ils proposent aussi bien OpenVPN que IPSEC.
J'ai fait un essai via OpenVPN en m’inspirant de la config "selective routing" de http://lg.io/2015/01/11/the-ubiquiti-edgerouter-configuring-this-extremely-lowcost-enterprisegrade-router-for-home-use.html (http://lg.io/2015/01/11/the-ubiquiti-edgerouter-configuring-this-extremely-lowcost-enterprisegrade-router-for-home-use.html).
Par rapport au fichier de conf proposé par le prestataire, j'ai dû ajouter -route-nopull et enlever -pull sans quoi tous les clients conectés au routeur passent par le VPN. Je ne suis d'ailleurs pas fan de l'instruction pull dans ce contexte :o, ça fait un peu chéque en blanc. Le résultat est mitigé car ça marche ... mais le client qui pointe vers le VPN utilise toujours les DNS Orange :( .
Bref, quelle serait la bonne façon de pousser sélectivement tout le trafic d'un groupe de clients vers le VPN en évitant les fuites DNS? Je préfère ne pas avoir de configuration à réaliser sur les clients. La version d'OpenVPN sur le FW 1.9 est déjà un peu ancienne ce qui est aussi est à considérer.
Merci
-
Je pense que c'est une histoire de Routing Policy ce que tu veux faire, il faut idéalement (si tu ne veux pas t'embéter) mettre tous les clients qui doivent passer par le VPN dans une RPZ, et la router spécifiquement. Après je ne l'ai jamais fait, je sais juste que ça existe (mais je peux tester, j'ai quelques tunnels sur mon ERL)
Pour ton histoire de DNS, je sais qu'avec mon DHCP, je peux pousser des DNS spécifiques en fonction du client, c'est difficile à maintenir mais je ne vois pas mieux.
Tu as -vraiment besoin- des DNS Orange ?
-
J'imagine que l'ERL fait office de serveur DHCP, et que l'adresse du serveur DNS poussée sur les clients est l'ERL lui-même... Donc dans ce cas c'est évidemment l'ERL qui fait les requêtes DNS aux résolveurs upstream (Orange par défaut) pour tous les postes clients, quelle que soit la routing policy.
Comme Hugues le propose, je suggère également de pousser des DNS différents par DHCP pour les clients qui sont routés dans le VPN, ensuite la routing policy fera le reste (normalement ;D )...
-
Je vais creuser l'idée de Hugues (RPZ) mais je ne connais pas à priori. Effectivement, l'ERL fait office de serveur DHCP et DNS pour les clients.
En fait, je ne tiens pas particulièrement aux DNS d'Orange. Je pourrais tout pousser ailleurs (service DNS forwarding system) mais je trouve pratique de conserver ceux d'Orange pour le tout-venant car ça permet justement d'identifier facilement les fuites. Sauf quant ils ne répondent plus mais c'est un autre sujet ;)
Ma crainte (justifiée) est que si je pousse les requêtes DNS vers un tiers, ces mêmes requêtes transiteront par le réseau de l'ISP et resteront par conséquent visibles. C'est pour cela que je cherche à pousser tout le trafic à travers le tunnel.
Le truc qui me chagrine est que les IP à faire transiter par le VPN sont sur le même sous réseau que les autres. Ce sont des machines virtuelles, donc physiquement connectées à mon réseau perincipal. En y réfléchissant, il me reste un port physique sur l'ERL et un NIC sur le serveur donc avec un peu de créativité...
PS : RPZ à creuser
-
Tu devrais pouvoir faire du 'destination nat' sur les IP des serveurs DNS avec un inbound sur le port LAN de l'ERL.
comme ca pour un PC qui va sortir par le VPN et qui fait une requete DNS tu peux NATer vers 8.8.8.8 l'IP local du server DNS (l'ERL lui-meme par exemple).
a tester.
-
Je progresse mais j'ai dû mettre ce projet entre parenthèses car j'ai d'autres gros changements en cours sur mon LAN.
SI je parviens à faire ce que je voulais, je mettrai les infos ici ... ou je viendrai crier au secours ;) si je bloque.
-
Tiens, pour ma part j'ai fait dans la simplicité:
- un VLAN dont tout le trafique passe par le VPN
- sinon c'est la connexion internet normal
- des règles de firewall entre le VLAN et le réseau normal pour ne laisser passer que ce que je veux
Et sur un point d'accès wifi, j'ai configuré 2 réseaux:
- un normal
- un autre connecté sur le VLAN
Si besoin, pour du filaire je peux toujours configurer un port du switch pour avoir le PID sur le VLAN.
Quoi qu'il en soit, avec les VLAN je peux facilement me connecter via VPN aux US (par exemple) juste en changeant de réseau wifi.
-
Intéressant. Tu n'as pas de DNS leakage?
-
Je n'ai pas testé, mais en distribuant les dns de google via dhcp je ne vois pas pourquoi ça ne passerai pas par le vpn.
-
Bon alors j'ai avancé sur la base des infos glanées ici et sur le net.
Tout fonctionne presque* comme attendu (j'ai bien un Vlan, qui est routé vers le VPN, y compris des requêtes DNS). Pour ceux que ça intéresse, je mets des éléments de config essentiels ci-dessous.
*En revanche, et c'est important, j'ai inclus un "kill switch" qui interdit au trafic des clients utilisant le Vlan (sensé transiter uniquement par le VPN) d'utiliser le WAN. C'est juste une addition à la règle de firewall WAN_OUT. Ca marche bien quand le vlan tombe mais il y a une truc bizarre: Dés que le VPN se re-connecte, il y a un intervalle de quelques secondes pendant lequel le trafic passe par le WAN! :o En bref, il y a encore du travail pour rendre le dispositif fiable. :'(. Je ne suis pas super à l'aise avec la source/destination de la règle en question.
Je pense reprendre la config de 0 car à force d'avoir le nez dedans, avec des interruptions à cause du boulot, je ne suis plus sûr de rien.
Si des spécialistes du firewall sur l'ERL peuvent me donner des idées, je suis preneur. Je me dois de souligner que je suis loin d'être un spécialiste des firewall, vlan et autres joyeusetés de l'ERL ;) et la méthode de configuration incrèmentale-itérative voit ici ses limites. :o
firewall {
…
modify SOURCE_ROUTE {
rule 10 {
action modify
description "traffic from a lan ip goes through vpn"
modify {
table 1
}
source {
address 192.168.55.0/24
}
}
}
…
name WAN_IN {
…
}
name WAN_LOCAL {
…
}
name WAN_OUT {
default-action accept
description "WAN OK except for VPN clients"
rule 1 {
action drop
description "Drop VPN direct WAN access"
destination {
group {
address-group NETv4_eth1
}
}
log disable
protocol all
source {
group {
address-group ADDRv4_eth2.55
}
}
}
}
…
}
interfaces {
ethernet eth0 {
…
}
ethernet eth1 {
address dhcp
description "WAN - Internet"
duplex auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
out {
name WAN_OUT
}
}
speed auto
}
ethernet eth2 {
…
vif 55 {
address 192.168.55.1/24
description "OpenVPN - client VLAN"
firewall {
in {
modify SOURCE_ROUTE
name PROTECT_IN
}
local {
name PROTECT_LOCAL
}
}
}
…
}
…
openvpn vtun9 {
… config du provider VPN ...
}
}
…
protocols {
static {
table 1 {
interface-route 0.0.0.0/0 {
next-hop-interface vtun9 {
}
}
}
}
}
…
service {
dhcp-server {
…
shared-network-name VPN_client_traffic {
authoritative disable
subnet 192.168.55.0/24 {
default-router 192.168.55.1
dns-server 8.8.8.8
dns-server 8.8.4.4
lease 86400
start 192.168.55.5 {
stop 192.168.55.15
}
}
}
…
-
WAN_OUT s'appliquant a 'out' de eth1 t'a juste besoin de preciser la source dans la regle 1. La tu precise aussi la destination mais ca limite qu'au ip local coté WAN.
supprime:
destination {
group {
address-group NETv4_eth1
}
}
de WAN_OUT.
ca bloquera tout ce qui vient de "ADDRv4_eth2.55"
version corrigée:
name WAN_OUT {
default-action accept
description "WAN OK except for VPN clients"
rule 1 {
action drop
description "Drop VPN direct WAN access"
log disable
protocol all
source {
group {
address-group ADDRv4_eth2.55
}
}
}
il faut bien comprendre que les règles de firewall c'est le contenu des regles + l'endroit et le sens ou elle sont appliqués (faut toujours prendre en compte les 2 même temps quand on construit les regles)
Dans le cas présent , WAN_OUT ne concerne que le 'out' de eth1:
ethernet eth1 {
address dhcp
description "WAN - Internet"
duplex auto
firewall {
in {
name WAN_IN
}
local {
name WAN_LOCAL
}
out {
name WAN_OUT
}
}
speed auto
}
si on est déjà a cette endroit et que la source est dans ADDRv4_eth2.55, alors on bloque et ce quelque soit la destination.
-
OK, merci.
C'est deja corrigé. je teste tout ça dès que possible!
-
Bon,
J'ai fait le ménage dans la config mais j'ai toujours une "fuite" quand le VPN tombe.
Je vais reprendre à 0.
-
Bon ça marche,
J'ai finalement remplacé
name WAN_OUT {
default-action accept
description "WAN OK except for VPN clients"
rule 1 {
action drop
description "Drop VPN direct WAN access"
log disable
protocol all
source {
group {
address-group ADDRv4_eth2.55
}
}
}
par
name WAN_OUT {
default-action accept
description "WAN OK except for VPN clients"
rule 1 {
action drop
description "Drop VPN direct WAN access"
destination {
group {
}
}
log disable
protocol all
source {
address 192.168.55.0/24
group {
}
}
}
}
pour une syntaxe avec laquelle je suis plus à l'aise et ça fonctionne.
-> tout le trafic des clients du Vlan passe par le tunnel, y compris les requêtes DNS
-> si le tunnel tombe, les clients du Vlan perdent leur accès à internet, les requêtes DNS n'aboutissent pas.
Faut que je voit s'il y aurait d'autres tests à faire pour rechercher d'éventuelles fuites mais c'est OK pour ce que je peux en juger.