OpenVPN / Routage / DNS => Configuration

Support Debian
#1

Bonjour tout le monde :slight_smile:

Je souhaiterais configurer un serveur VPN et connecter mes clients de sorte à ce que ce réseau respectent certaines règles :

  • Les clients seront des téléphone Android, utilisant un fichier de configuration OpenVPN DIFFERENT pour chaque clients.

  • Toutes les requêtes DNS interrogeront un serveur DNS accessible uniquement par le VPN

  • Seulement certains sites WEB seront accessible par le VPN

Voila comment je comptais procéder :

  • Acheter un nom de domaine (ex: myvpnserver.com) pour définir la cible dans le fichier de configuration du VPN

  • Utiliser un logiciel tel qu’unbound pour gérer mes domaines locaux (ex : mysite1.customtld mysite2.customtld)

  • Unbound sera quant a lui configurer pour se servir sur les serveur racine du DNS

Voici comment je vois une connexion s’effectuer sur un site interne :

Le client 1 souhaite se connecter au site mysite1.customtld :

  • Requette DNS via le VPN connecté sur l’adresse 10.8.0.100
  • réponse du DNS mysite1.customtld = 10.8.0.101
  • accès à la ressource via le VPN
    (Evidemment tous ces services ne seront accessible que par des IP situé dans 10.8.0.0/16 ou 10.8.0.0/24 (je n’ai pas encore réfléchis à ça mais il me semble judicieux de séparer mon infra de serveur dans un sous domaine différent de mes clients)

Le client 2 peux quant a lui se connecter à un site interne via le VPN mais la il souhaite se connecter au www :

  • Requete DNS via le VPN
  • réponse DNS google.com = x.x.x.x
  • accès à la ressource directement à x.x.x.x sans passer par le VPN

Je sais pas si ce post est très clair mais je ne sais pas du tout comment embarquer cette configuration sur le client…

je ne sais d’ailleur même pas s’il est possible en utilisant openvpn de ne faire passer qu’une partie du trafic réseaux par OpenVPN

Alors mes deux grandes questions sont :

  • Le fichier de configuration OpenVPN peut-il embarquer toutes cette configuration ?
  • Cette solution d’isolation est-elle optimisée ?

Il est évident que les site *.customtld seront accessible uniquement par VPN, d’ailleur le seul port OpenVPN sera ouvert sur le routeur…

Désolé du foutoir, mais merci de m’avoir lu.

#2

Ton domaine interne n’est pas routable sur Internet et ton serveur DNS n’est joignable qu’en interne (et en VPN). Du coup, tu n’as rien de particulier à régler de ce point de vue.
Concernant le routage, tu peux demander à ton serveur OpenVPN d’envoyer des routes seulement pour ton réseau interne et laisser le client se débrouiller tout seul avec ce qu’il a pour aller sur Internet.

Après, pour ça :

Je ne sais pas du tout comment ça fonctionne, je ne peux pas t’aider…

#3

Salut :slight_smile:

Merci de m’avoir répondu, je ne savais pas qu’un serveur OpenVPN pouvais envoyer des règles de routage au client, et c’est sur ce point alors que je ne sais pas comment faire…

#4

Alors, d’après la configuration que j’ai là, ce serait l’option push. Voici ce que j’ai :

push "route 192.168.1.0 255.255.255.0"
push "dhcp-option DNS 192.168.1.245"
push "dhcp-option DOMAIN example.com"

Le poussage de route dit juste au client de passer par la connexion VPN pour aller sur le réseau défini.

#5

Salut, merci pour vos réponses, je viens de configurer en premier lieux un serveur vpn de test hébergé sur un Raspi.

J’ai réussi à configurer au moins le server ainsi que le client.

Je peux me connecter au VPN depuis l’extérieur, j’ai bien accès au service du server (Samba, Cups etc…) Mais le problème c’est que je n’ai pas accès aux machines du réseaux local du serveur VPN

par contre je suis bien capable de router le traffic internet en dehors du VPN

En savez vous plus ?? voici la conf du serveur

# Protocole et interface
mode server
proto udp
port 1194
dev tun

# Chemin vers les clefs
ca              keys/server/ca.crt
cert            keys/server/server.crt
key             keys/server/server.key
dh              keys/server/dh2048.pem
tls-auth        keys/server/ta.key 0
cipher          AES-256-CBC



# Réseaux

server  10.8.0.0 255.255.255.0
push    "route 192.168.1.0 255.255.255.0"
ifconfig-pool-persist   ipp.txt
keepalive               10 120


# Sécurité

user    nobody
group   nogroup
chroot /etc/openvpn/jail
persist-key
persist-tun
comp-lzo

# Logs
verb 9
mute 20
status openvpn-status.log
log-append /etc/openvpn/openvpn.log
#6

Les routes nécessaires dans les deux sens sont-elles en place sur toutes les machines impliquées ? Le “forwarding” des paquets est-il activé ? Les paquets forwardés sont-ils autorisés par les règles iptables ?

Que veux-tu dire ?

#7

Salut pascal et merci,
Je crois avoir compris et tu viens de me mettre la puce à oreille,

Alors après mon post j’ai activer l’IP forwarding, je peux maintenant me connecter depuis le client sur tout les équipements du réseaux local du serveur.
Je me trouve maintenant confronté à un autre problèmes…

Je souhaiterais interdire le traffic du client VPN vers ma passerelle par défaut(192.168.1.254) du lan du serveur

Et aussi pouvoir intégrer dans mon serveur DHCP des routes me permettant de me connecter aux clients…
(de 192.168.1.0/24 ver 10.8.0.0/24)
Pour ne pas avoir à configurer manuellement les routes sur des appareils avec des OS différents…

Mais je devrais plutôt me former sur iptables, et approfondir OpenVPN ainsi que isc-dhcp-server… Je crois !!

#8

Merci bien Almtesh, j’ai effectivement configurer les routes, mais j’ai abandonner l’idée de la gestion du domaine, en fait la connexion au DNS de mon lan s’est bien passée, mais j’utilise un raspberry pi comme serveur, et disons qu’il fait déjà tourner pas mal de choses, je vais pas le surcharger avec ça sachant qu’il est vieux et tourne pour un rien à plein régime…

#9

Vers la passerelle ou plutôt au delà, vers internet ?
Dans quel but ?

Il y a plusieurs possibilités.
La plus évidente : avec des règles iptables dans la chaîne FORWARD, par exemple :

iptables -A FORWARD -s 10.8.0.0/24 ! -d 192.168.1.0/24 -j REJECT --reject-with icmp-admin-prohibited

Une autre consiste à mettre en place des règles de routage avancé, mais c’est un peu plus délicat.

Ah, sujet épineux.
Il faut que le serveur DHCP et les clients supportent l’option “classless static routes” puisque le préfixe 10.8.0.0/24 ne correspond pas à une des anciennes classes A, B ou C. La dernière fois que j’avais regardé, le serveur ISC DHCP ne connaissait pas nativement cette option, il fallait la définir de façon brute avec son numéro et ses paramètres sous forme d’octets. Si on n’est pas regardant, on peut utiliser l’option “static routes” (static-routes dans ISC DHCP) avec tout le préfixe 10.0.0.0/8 (classe A).

Une autre possibilité consiste à ajouter une route pour 10.8.0.0/8 sur la passerelle du réseau local.

Sinon, il y a un moyen pas très propre d’éviter de mettre en place des routes si cela ne sert que pour contacter des machines du LAN depuis le VPN et pas l’inverse : utiliser du NAT source SNAT ou MASQUERADING avec iptables.

#10

Et bien rebonjour, voici la solution que j’ai trouver :

Configuration du serveur

# Protocole et interface
mode server
proto udp
port 1194
dev tun

# Chemin vers les clefs
ca		keys/server/ca.crt
cert		keys/server/server.crt
key		keys/server/server.key
dh		keys/server/dh2048.pem
tls-auth	keys/server/ta.key 0
cipher		AES-256-CBC



# Réseaux

# Attribution des addresses ip sur le subnet 10.8.0.0/24
server	10.8.0.0 255.255.255.0
# Routes pour le réseaux local
push	"route 192.168.1.0 255.255.255.0"
ifconfig-pool-persist	ipp.txt
keepalive		10 120


# Sécurité

user	nobody
group	nogroup
chroot /etc/openvpn/jail
persist-key
persist-tun
comp-lzo

# Logs 
verb 9
mute 20
status openvpn-status.log
log-append /etc/openvpn/openvpn.log

Configuration de la table NAT d’IPTABLES

Ouverture du LAN serveur aux clients du VPN

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  10.8.0.0/24          anywhere

Routes DHCP

Routes pour les clients Windows et Linux du Lan Server vers les clients VPN

option classless-routes code 121 = array of unsigned integer 8;
option classless-routes 24, 10,8,0, 192,168,1,200;
option classless-routes-win code 249 = array of unsigned integer 8;
option classless-routes-win 24, 10,8,0, 192,168,1,200;

Règles IPTABLES

Les clients du VPN ne peuvent accéder qu’au équipements sur 192.168.1.0/24 SAUF la passerelle par défaut.

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination        
DROP       all  --  10.8.0.0/24          192.168.1.254       
ACCEPT     all  --  10.8.0.0/24          192.168.1.0/24      
DROP       all  --  10.8.0.0/24          anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
#11

Et bien en fait, le but c’est de pouvoir faire du jeu en LAN à distance :smiley:
Je sais que ça séloigne un peu du sujet d’origine, mais j’ai préférer reprendre ce sujet plutot que d’en créer un autre, ça m’a quand même permis de pouvoir au final faire ce que je voulais faire à l’origine, en ajoutant simplement une regle DNS dans le VPN, mais comme dis plus haut mon raspberri supporte mal la floppée de service installée…

Elle fait mal cette ligne…
Pourquoi utiliser ?

 -j REJECT --reject-with icmp-admin-prohibited
ainsi que
    !

Je suis encore un néophyte d’IPTABLES et d’openVPN

@PascalHambourg La solution te semble correcte ?

#12

L’affichage des règles par iptables -L est incomplet. Il faut utiliser iptables-save.

Que veux-tu dire ?

! sert à inverser la condition qui suit. La règle s’applique dont aux paquets dont la destination n’est pas dans 192.168.1.0/24.

REJECT sert à envoyer un message pour informer la source que le paquet a été bloqué. C’est plus propre qu’un blocage silencieux. Cela peut éviter les délais d’attente d’une réponse qui ne viendra jamais.

#13

Salut pascal, voici l’intégrale des règles iptables

# Generated by iptables-save v1.6.0 on Tue Sep 18 12:18:46 2018
*nat
:PREROUTING ACCEPT [13071:1823422]
:INPUT ACCEPT [12742:1805228]
:OUTPUT ACCEPT [46873:3715952]
:POSTROUTING ACCEPT [46873:3715952]
-A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue Sep 18 12:18:46 2018
# Generated by iptables-save v1.6.0 on Tue Sep 18 12:18:46 2018
*filter
:INPUT ACCEPT [3315666:446587751]
:FORWARD ACCEPT [5233:4179240]
:OUTPUT ACCEPT [3697793:462407099]
-A FORWARD -s 10.8.0.0/24 -d 192.168.1.254/32 -j REJECT --reject-with icmp-admin-prohibited
-A FORWARD -s 10.8.0.0/24 ! -d 192.168.1.0/24 -j REJECT --reject-with icmp-admin-prohibited
COMMIT
# Completed on Tue Sep 18 12:18:46 2018
# Generated by iptables-save v1.6.0 on Tue Sep 18 12:18:46 2018
*mangle
:PREROUTING ACCEPT [3321223:450784845]
:INPUT ACCEPT [3315671:446588011]
:FORWARD ACCEPT [5384:4189380]
:OUTPUT ACCEPT [3697798:462407995]
:POSTROUTING ACCEPT [3706754:467122112]
COMMIT
# Completed on Tue Sep 18 12:18:46 2018
#14

A première vue cela devrait faire ce que tu veux.