Serveur dédié : VPN et site web privés

Support Debian
#1

Bonjour ! :slight_smile:

Sur mon server dédié j’ai mis en place un VPN openVPN. Cela fonctionne bien.
J’ai mis en place une page web via nginx sur un port xxx bloqué par iptables sauf pour l’ip de mon serveur.

Mon objectif est que seul les personnes connectés au VPN puisse accéder à ce site.

Mon problème est que çà ne marche pas ! :stuck_out_tongue:

En ouvrant le port, évidement, je peux afficher la page web, mais dans les logs de nginx, étrangement, l’ip de connexion n’est pas celle de mon serveur mais bien celle fournit par mon FAI, alors même que je suis bien connecté à mon VPN et que les site de détection d’IP détecte bien l’IP du serveur…

Qu’est-je donc loupé ou pas compris ? Mon IP de navigation du serveur vers lui même ne devrait-elle pas être celle de mon VPN et non celle de mon FAI ?

#2

Ça ne va pas être très utile si seul le serveur lui-même a accès à son propre serveur web.

Je confirme, ça ne peut pas marcher. Deux causes :

  1. Les communications entre un client du VPN et l’adresse IP publique du serveur (celle utilisée pour établir le VPN) ne passent pas dans le VPN à cause d’une route qui est ajoutée lorsque le VPN est établi. Tu peux le vérifier avec la commande ip route. Cette route a pour rôle d’empêcher que les paquets qui transportent le VPN ne soient pas envoyés dans le VPN, sinon ça ne marcherait pas (problème de poule et d’oeuf).
    Solution : utiliser une adresse IP différente, par exemple l’adresse de l’interface VPN du serveur.

  2. Même si les communications passent par le VPN, l’adresse source des paquets HTTP ne sera pas celle du serveur, donc iptables bloquera encore. Tu as probablement créé une règle SNAT ou MASQUERADE en POSTROUTING sur le serveur, mais cette règle ne s’applique pas aux paquets à destination du serveur lui-même et qui ne ressortent pas car ils ne traversent pas cette chaîne.
    Solution : filtrer sur l’interface d’entrée du VPN (tunX ou tapX selon le mode), ou sur l’adresse source qui doit être dans la plage allouée par le VPN.

#3

Bonjour Pascal,

Merci de ta réponse très instructive.

Suite à ma lecture, malgré mes connaissances limitées, j’ai essayé d’accepter toutes les connections depuis l’interface du VPN, ce qui me semble être la bonne méthode. J’ai ajouter ces deux règles iptables :

iptables -A INPUT -i tun0 -j ACCEPT
iptables -A FORWARD -i tun0 -j ACCEPT

Cependant l’accès à mon site reste bloqué.

Je creuse le sujet en essayant d’en comprendre un peu plus…

En attendant, ci cela peut aider à comprendre mon problème, voici le résultat d’iptables-save (j’ai retiré les règles fail2ban) :

# Generated by iptables-save v1.6.0 on Sat Jul 15 17:48:46 2017
*raw
:PREROUTING ACCEPT [2387205:729379667]
:OUTPUT ACCEPT [949410:621398460]
COMMIT
# Completed on Sat Jul 15 17:48:46 2017
# Generated by iptables-save v1.6.0 on Sat Jul 15 17:48:46 2017
*nat
:PREROUTING ACCEPT [99162:8262604]
:INPUT ACCEPT [42129:1479814]
:OUTPUT ACCEPT [19906:3889489]
:POSTROUTING ACCEPT [77:5444]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Sat Jul 15 17:48:46 2017
# Generated by iptables-save v1.6.0 on Sat Jul 15 17:48:46 2017
*mangle
:PREROUTING ACCEPT [2387205:729379667]
:INPUT ACCEPT [834071:136522014]
:FORWARD ACCEPT [1550610:592346448]
:OUTPUT ACCEPT [949410:621398460]
:POSTROUTING ACCEPT [2485713:1212761407]
COMMIT
# Completed on Sat Jul 15 17:48:46 2017
# Generated by iptables-save v1.6.0 on Sat Jul 15 17:48:46 2017
*filter
:INPUT DROP [65:4836]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [1194:104778]
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 53 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 953 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 25 -j ACCEPT
-A INPUT -p icmp -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 53 -j ACCEPT
-A INPUT -p udp -m udp --dport 123 -j ACCEPT
-A INPUT -i tun0 -j ACCEPT
-A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o eth0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
COMMIT
# Completed on Sat Jul 15 17:48:46 2017
#4

Je ne vois pas la règle qui correspond à ce que tu as écrit dans ton message initial :

un port xxx bloqué par iptables sauf pour l’ip de mon serveur.

Est-ce le port 80, qui est autorisé inconditionnement ?

La dernière règle dans FORWARD ne sert à rien. Les deux dernières règles dans FORWARD devraient être fusionnées en une seule.

#5

Oui, je l’ai retirée :

iptables -A INPUT -p tcp -m tcp --dport 8080 -s X.XXX.XXX.XX -j ACCEPT

Le port 80 est autorisé oui, mes sites privées seront sur les port 80XX.

#6

Vu. La règle que tu as ajoutée dans INPUT pour autoriser les connexions depuis le VPN est correcte, mais ne suffit pas. Elle ne corrige que la cause n° 2. Il faut encore corriger la cause n° 1.

Il y a plusieurs méthodes possibles. La plus simple consiste à se connecter à une autre adresse IP que celle de la connexion VPN. Pour cela, l’adresse doit être configurée sur une des interfaces réseau du serveur. Cela peut être l’interface tun0 du VPN et son adresse normale, l’interface de loopback lo avec n’importe quelle adresse (mais pas une adresse en 127.*). Cette adresse doit être routée par le VPN ; c’est déjà le cas si c’est l’adresse de tun0 ou si la route par défaut des clients passe par le VPN. Et le serveur web doit écouter sur cette adresse (ou écouter sur n’importe quelle adresse locale : 0.0.0.0).

Les autres méthodes impliquent des modifications sur les clients (règles iptables, routage avancé…) et pas seulement côté serveur.

#7

Désoler je ne comprend pas ! Mon poste client est sous Mac Os X et j’utilise Tunnelblick pour me connecter…

J’ai quand même essayé de faire ce que tu explique. Pour faire au plus simple vu mes connaissance, j’ai voulu passer par l’adresse de l’interface du VPN :

# ifconfig
tun0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1500
        inet 10.8.0.1  netmask 255.255.255.0  destination 10.8.0.1
...

# ip route
default via 5.135.152.254 dev eth0 onlink 
5.135.152.0/24 dev eth0 proto kernel scope link src 5.135.152.81 
10.8.0.0/24 dev tun0 proto kernel scope link src 10.8.0.1

J’ai configuré mon instance nginx pour écouter en local :

listen 0.0.0.0:8080

Et j’ai ouvert les connections depuis l’interface dans iptables :

iptables -A INPUT -p tcp -m tcp --dport 8080 -s 10.8.0.1 -j ACCEPT

Ca ne marche toujours pas, il doit me manquer cette histoire de connexion que je ne comprend pas…

#8

Il y a une anomalie dans la configuration IP de tun0 : les adresses IP locale et distante sont identiques. Elles devraient être différentes.

A mon avis cela ne peut être qu’un bug de configuration de l’adresse distante sur le client car si le serveur avait vraiment la même adresse que le client alors les communications via le VPN ne fonctionneraient pas du tout.

Si le serveur et le client ont la même adresse, alors quand le client essaie de se connecter à cette adresse il va en fait essayer de se connecter à lui-même et pas au serveur. Il faut se connecter à l’adresse qui est sur l’interface tun du serveur, et qui doit être différente.

Edit : Les commandes ifconfig et ip route ont été exécutées sur le client ou le serveur ? Je pensais initialement que c’était sur le client mais comme ip est spécifique à Linux et n’existe pas sur MacOS, je suppose que c’est plutôt sur le serveur.

Dans ce cas ta nouvelle règle iptables n’est pas bonne : elle doit se baser sur l’interface d’entrée donc “-i tun0” ou la vraie adresse de l’interface tun du client qui n’est pas 10.8.0.1 mais une autre adresse dans le bloc 10.8.0.0/24 donc “-s 10.8.0.0/24”.