Connexion externe impossible

Support Debian
#1

Bonjour à tous,

En faisant joujoue avec les iptables de mon kimsufi (car mon openvpn n’avait plus d’accès à internet et j’essayais de trouver pourquoi…) j’ai visiblement bloqué toutes ses connexions externes. Du moins un telnet sur le port 22, 80, 1723 et tous les autres ports que je pouvais avoir d’ouverts est impossible.

Voici les commandes que j’avais tapé juste avant que ça plante:

sudo iptables -F sudo iptables -X sudo iptables -P INPUT DROP sudo iptables -P OUTPUT ACCEPT sudo iptables -P FORWARD DROP sudo iptables -A INPUT -i lo -j ACCEPT sudo iptables -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

J’ai donc booté mon serveur en rescue mode, monté mon disque, chrooté le disque monté, mais malgré toutes les manipulations possibles via cet environnement au reboot mon serveur reste inaccessible…

Ce que j’ai tenté via mon rescue mode avec chroot de mon /dev/sda2:

[ul]

  • Faire un iptables -F puis un iptables-save, pas marché.
  • Ajouter des commandes à mon rc.local de faire un flush et de tout accepter pour que ça fonctionne au reboot, pas marché.
  • Supprimer /etc/iptables.rules, pas marché.
    [/ul]

Le plus étrange semble être que malgré mes ajouts de règle ou autre via la commande iptables en rescue mode, à chaque reboot + chroot mon iptables -L est vide…

Bref, je suis complètement perdu et j’aurais bien besoin d’aide en gros noob que je suis…

Merci d’avance!

#2

Je me plante peut-être, mais l’option -F de iptables supprime les règles, mais ne change pas le “Policy” par défaut. C’est iptables -X qui remet tout à zéro.

Vérifie aussi que ce n’est pas un bête problème de réseau. Les connexions sortants passent-elles ?

#3

Dunatotatos : tout bon pour -F, mais tout faux pour -X qui ne fait que supprimer les chaînes utilisateur vides et ne touche à rien d’autre. Pour modifier la politique par défaut d’une chaîne il faut utiliser -P ou bien iptables-restore avec le contenu qui va bien.

Chop : les règles et politiques d’iptables sont volatiles et doivent être rechargées à chaque démarrage. Le démarrage du serveur en mode rescue (à ne pas confondre avec le mode dépannage/rescue dans le menu de démarrage de GRUB) lance un environnement totalement distinct de ton système normal, c’est donc normal qu’aucune règle n’y soit présente et toute commande iptables exécutée dans cet environnement sera sans effet sur le système normal. Par contre si les règles sont en place à chaque redémarrage en mode normal, c’est forcément que quelque chose les a mémorisées et appliquées.

Où as-tu tapé ces règles iptables ? Directement dans le shell de la console SSH, ligne par ligne ? Dans ce cas cela aurait dû bloquer immédiatement après la 3e ligne et ne pas persister après un reboot. Dans un script ? Lequel ? Exécuté comment ?

#4

Bonjour à tous les 2 et merci pour vos réponses!

Je crois avoir bien compris le principe du rescue mode après l’avoir trifouillé toute la journée d’hier! Ce qui n’est visiblement pas encore clair pour moi c’est l’utilisation du chroot. Je croyais avoir compris qu’en montant mon disque dans un dossier quelconque et en chrootant ledit dossier, je “simulerais” d’être sur mon système classique comme si de rien était. Est-ce bien le cas? Si oui, les instructions d’iptables que je tape une fois le chroot effectué ne devraient-elles pas fonctionné?

2ème chose étrange, si effectivement comme j’avais cru le comprendre, les iptables ne sont pas naturellement persistantes et que je dois normalement les recharger à chaque boot, la policy m’empêchant toute connexion au serveur n’aurait-elle pas du disparaitre avec un simple reboot du serveur? J’avoue que je suis un peu perdu vis-à-vis de ça…

@Dunatotatos: N’ayant plus accès à rien en mode normal sur le serveur, je ne peux pas tester grand chose. La machine ping, pas de problème et en mode rescue le petit pannel qu’OVH propose sur le port 81 pour tester un peu tout le serveur n’indique aucun problème quel qu’il soit (il comprend un test de “connexion” ordi -> serveur -> datacenter si je ne m’abuse)

@PascalHambourg: Les règles que j’ai tapé, je les ai fait à la bourrin comme à mon habitude :slightly_smiling: J’avais copié collé les commandes d’un site expliquant comment essayer de réparer mon openvpn. Je les ai donc collé tout d’un coup et seul la dernièrement commande ne s’est pas executé je pense car il fallait que je la confirme en appuyant sur entrée, ce que je n’ai pas eu le temps de faire avant pas deconnexion forcée… Donc ces commandes ont été collées manuellement dans un shell en tant que root.

Encore merci pour votre aide! :wink:

#5

Il faut aussi monter d´autres répertoires (comme /proc). Les tutos sont nombreux sur le sur ce sujet, je te laisse en chercher un.

Si, en effet. Sauf si tu utilises un service pour enregistrer les rèlges (comme iptables-persistent). D´où ma question sur le réseau.
Peux-tu d´ailleurs nous donner la sortie de ifconfig, ainsi que de route -n ?

Enfin, pourquoi t´acharnes-tu à démarrer en mode rescue ? Le panel d´OVH propose une console même si tu démarres en mode normal.

#6

Ok je vais regarder les tutos sur le sujet.

[quote=“Dunatotatos”]Si, en effet. Sauf si tu utilises un service pour enregistrer les rèlges (comme iptables-persistent). D´où ma question sur le réseau.
Peux-tu d´ailleurs nous donner la sortie de ifconfig, ainsi que de route -n ?

Enfin, pourquoi t´acharnes-tu à démarrer en mode rescue ? Le panel d´OVH propose une console même si tu démarres en mode normal.[/quote]

Je n’ai pas installé de moi même iptables-persistent AVANT le problème en principe, je l’ai par contre fait après dans le but de justement pouvoir m’assurer que les iptables seraient bien remises à 0 définitivement. Sans succès.

Mon ifconfig:

eth0      Link encap:Ethernet  HWaddr 00:25:90:0d:44:64  
          inet adr:91.121.XXX.130  Bcast:91.121.XXX.255  Masque:255.255.255.0
          adr inet6: fe80::225:90ff:fe0d:4464/64 Scope:Lien
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:1215967 errors:0 dropped:0 overruns:0 frame:0
          TX packets:1410086 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:251293937 (239.6 MiB)  TX bytes:1514512358 (1.4 GiB)
          Interruption:16 Mémoire:fb5e0000-fb600000 

eth1      Link encap:Ethernet  HWaddr 00:25:90:0d:44:65  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
          Interruption:17 Mémoire:fb6e0000-fb700000 

lo        Link encap:Boucle locale  
          inet adr:127.0.0.1  Masque:255.0.0.0
          adr inet6: ::1/128 Scope:Hôte
          UP LOOPBACK RUNNING  MTU:65536  Metric:1
          RX packets:65339 errors:0 dropped:0 overruns:0 frame:0
          TX packets:65339 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 lg file transmission:0 
          RX bytes:23214234 (22.1 MiB)  TX bytes:23214234 (22.1 MiB)

Mon route -n:

Table de routage IP du noyau
Destination     Passerelle      Genmask         Indic Metric Ref    Use Iface
0.0.0.0         91.121.XXX.254  0.0.0.0         UG    0      0        0 eth0
91.121.XXX.0    0.0.0.0         255.255.255.0   U     0      0        0 eth0

Enfin je n’ai personnellement aucune console sur mon panel kimsufi. Tout ce que je peux faire, c’est démarrer sur le disque dur / réseau ou netboot (rescue mode).
Si tu peux m’indiquer comment acceder à cette fameuse console, ça m’aiderait effectivement beaucoup :wink:

#7

Ah, je me suis planté, il n´y a pas de console KVM sur les serveurs kimsufi. Dommage.

Une fois que tu as chrooté correctement ta machine. Peux-tu nous donner la sortie exacte de iptables-save (ou iptables -L) ?

EDIT : Si l´adresse IP indiquées dans ton précédent post est correcte, j´ai une bonne nouvelle pour toi. Ta machine répond au ping, à SSH, et le serveur web est accessible aussi.
Du coup, ce serait plutôt un problème de ton client. Tu te connectes via l´adresse IP ou un nom de domaine ?

#8

[quote=“Dunatotatos”]Ah, je me suis planté, il n´y a pas de console KVM sur les serveurs kimsufi. Dommage.

Une fois que tu as chrooté correctement ta machine. Peux-tu nous donner la sortie exacte de iptables-save (ou iptables -L) ?

EDIT : Si l´adresse IP indiquées dans ton précédent post est correcte, j´ai une bonne nouvelle pour toi. Ta machine répond au ping, à SSH, et le serveur web est accessible aussi.
Du coup, ce serait plutôt un problème de ton client. Tu te connectes via l´adresse IP ou un nom de domaine ?[/quote]

Donc ce que j’ai fait pour que l’on soit sûr d’après un extrait d’un des seuls tutos que j’ai trouvé qui avait l’air pertinent:

mount /dev/sda2 /mnt
cd /mnt
mount --bind /proc proc 
mount --bind /sys sys
chroot . /bin/bash
umount sys
umount proc

En résultat mon iptables -L return un fichier complètement vide et avec des Policy ACCEPT partout…

[code]Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination [/code]

EDIT:

Oui c’est normal qu’elle réponde à tout en ce moment, c’est mon mode rescue qui fonctionne et j’ai relancé mes services une fois le chroot effectué, en mode normal plus rien ne marche par contre…

#9

Comment as-tu pu l’installer si tu n’arrives plus à te connecter à ton serveur en mode normal, sans passer par un chroot ?

Tu dois inspecter tout ce qui est susceptible de créer des règles iptables au démarrage.
Les scripts d’init dans [mono]/etc/init.d/[/mono]
Les scripts d’activation réseau dans [mono]/etc/network/if-*-up.d/[/mono]
Les commandes exécutées par [mono]/etc/rc.local[/mono]

Par contre tu écris que le serveur démarré en mode normal répond au ping ? Les règles iptables que tu as citées ne le permettent pas.