Ping: sendmsg: erreur d'opération non autorisée après l'installation d'iptables sur Arch GNU / Linux

Hier, j'ai eu un nouvel ordinateur comme serveur domestique, un microserveur HP Proliant. Installé Arch Linux dessus, avec la version du noyau 3.2.12.

Après avoir installé iptables (1.4.12.2 - la version actuelle AFAIK) et changé la net.ipv4.ip_forwardclé à 1, et activé le transfert dans le fichier de configuration iptables (et le redémarrage), le système ne peut utiliser aucune de ses interfaces réseau. Ping échoue avec

Ping: sendmsg: operation not permitted

Si je supprime complètement iptables, la mise en réseau est correcte, mais je dois partager la connexion Internet au réseau local.

eth0 - carte réseau Wan intégrée sur la carte mère (Broadcom NetXtreme BCM5723).

eth1 - carte réseau LAN dans un emplacement pci-express (Intel 82574L Gigabit Network)

Puisqu'il fonctionne sans iptables (le serveur peut accéder à Internet et je peux me connecter avec ssh depuis le réseau interne), je suppose qu'il a quelque chose à voir avec iptables. Je n'ai pas beaucoup d'expérience avec iptables, donc je les ai utilisées comme référence (distinctes les unes des autres bien sûr ...):

wiki.archlinux.org/index.php/Simple_stateful_firewall#Setting_up_a_NAT_gateway

revsys.com/writings/quicktips/nat.html

howtoforge.com/nat_iptables

Sur mon serveur précédent, j'ai utilisé le guide revsys pour configurer nat, fonctionnait comme un charme.

Quelqu'un a déjà vécu quelque chose comme ça avant? Qu'est-ce que je fais mal?

— estol
source

Réponses:

Le message d'erreur:

Ping: sendmsg: operation not permitted

signifie que votre serveur n'est pas autorisé à envoyer des paquets ICMP. Vous devez autoriser votre serveur à envoyer du trafic via une ou plusieurs des interfaces configurées. Vous pouvez le faire en:

Définissez la OUTPUTstratégie de chaîne ACCEPTpour autoriser tout le trafic sortant de votre box:
```
sudo iptables -P OUTPUT ACCEPT
```
Définissez la OUTPUTstratégie de chaîne sur DROP, puis autorisez de manière sélective le type de trafic dont vous avez besoin.

Cela s'applique à toutes les chaînes, pas seulement à la OUTPUTchaîne. INPUTla chaîne contrôle le trafic reçu par votre box. FORWARDla chaîne traite le trafic acheminé via la boîte.

— Khaled
source

Ping n'était qu'un exemple, ne pouvait pas envoyer de paquets udp, ni de paquets tcp ...

— estol

Même si, la même idée s'applique

— Khaled

J'ai essayé ce que vous avez dit, mêmes résultats. Vous avez les règles de l'ancien serveur, cela fonctionne partiellement. Tout client peut rechercher des noms de domaine, même en mesure de les cingler, mais ne peut pas naviguer sur le Web. J'ai installé un proxy comme solution de contournement (car la connexion sur le serveur est correcte, tout comme la connexion au serveur) mais de nombreux services ne fonctionnent pas (Trillian, Skype) de cette façon.

— estol

Quelle est la commande pour définir la stratégie de chaîne de sortie à accepter ??

— Joseph Astrahan

@JosephAstrahan:sudo iptables -P OUTPUT ACCEPT

— Khaled

Pour moi, sur Debian 9, cela n'a aidé qu'à réinstaller ping:

apt-get install --reinstall iputils-ping

— Dawid Ferenczy Rogožan
source

A également travaillé sur CentOS 7 (mise à niveau du package en fait yum upgrade iputils.x86_64), après le clonage du système d'exploitation "physique" sur une machine virtuelle - je ne sais pas si cela importe.

— yahol