iptables bloque uniquement OpenVPN lors du démarrage du server

Je suis actuellement en train de configurer OpenVPN sur plusieurs centres de données sur Linode. La configuration OpenVPN fonctionne bien et je me concentre maintenant sur la mise en place de mon pare-feu afin que mes adresses IP publiques et privées fournies par Linode soient protégées.

Cependant, je semble avoir un problème avec cela. Sur mon server VPN, lorsque j'ai configuré mon pare-feu et redémarré le server VPN, le pare-feu est chargé au démarrage automatiquement, mais aucun de mes clients VPN ne semble pouvoir faire un ping sur le server VPN (situé au 10.8.0.1 ). Lorsque je retire mon pare-feu sur le server VPN ( iptables -F ), les clients sont capables de faire un ping sur le server VPN. Lorsque je réinstaure mon pare-feu sur le server ( iptables-restore < /etc/iptables.up.rules ), les clients sont toujours en mesure de faire un ping sur le server VPN.

Je suppose que le pare-feu soit bloqué ou non et je ne peux pas imaginer pourquoi ce comportement se produit.

Ce sont mes iptables sur le server VPN:

 *filter # Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0 -A INPUT -i lo -j ACCEPT -A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT # Accepts all established inbound connections -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT # Allows all outbound traffic # You can modify this to only allow certain traffic -A OUTPUT -j ACCEPT # Allows SSH connections # # THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE # -A INPUT -p tcp -m state --state NEW --dport 30000 -j ACCEPT # Allow ping -A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT # log iptables denied calls -A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7 # Reject all other inbound - default deny unless explicitly allowed policy -A INPUT -j REJECT -A FORWARD -j REJECT # prevent attacks on port 22. -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --set -I INPUT -p tcp --dport 22 -i eth0 -m state --state NEW -m recent --update --seconds 90 --hitcount 4 -j DROP # OpenVPN -A INPUT -i eth0:0 -m state --state NEW -p udp --dport 1194 -j ACCEPT -A INPUT -i eth0:1 -m state --state NEW -p udp --dport 1194 -j ACCEPT # Allow TUN interface connections to OpenVPN server -A INPUT -i tun+ -j ACCEPT # Allow TUN interface connections to be forwarded through other interfaces -A FORWARD -i tun+ -j ACCEPT -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT COMMIT # NAT the VPN client traffic to the internet *nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE COMMIT 

Le pare-feu ne bloque pas les connections VPN déjà établies parce que vous avez la règle suivante près du haut:

 -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT 

Cela signifie que les connections déjà dans l'état ESTABLISHED (du sharepoint vue du module conntrack du netfilter) continueront à traverser.

De plus, très probablement, votre string INPUT a une «politique» d' ACCEPT ; C'est pourquoi faire iptables -F ouvert votre pare-feu, permettant à OpenVPN de créer la connection.

Notez que même lorsque les règles netfilter sont rincées, les connections sont encore en cours de suivi.

En résumé, ce qui s'est passé était:

  1. Firewall a bloqué la tentative de connection OpenVPN
  2. Les règles ont été rincées
  3. OpenVPN peut se connecter ==> transitions d'état à ESTABLISHED
  4. Les règles ont été réembeddedes
  5. Le trafic OpenVPN peut reprendre car l'état ESTABLISHED