[Résolu] Plus d'accés au serveur web (nginx)

Ce site est optimisé pour être consulté depuis un navigateur moderne dans lequel JavaScript est activé.

[Résolu] Plus d'accés au serveur web (nginx)

nadrelaxe

Bonjour à tous,

Aujourd'hui je bossais tranquillement sur mon serveur et lorsque j'ai voulu modifier un fichier de conf de nginx j'ai fais un

service nginx stop

Jusque la normal.

J'ai fais mon fichier de conf sans problème et en faisant un

service nginx start

J'ai eu aucune erreur nginx a redémarré. Mais depuis il m'est impossible d'accéder à n'importe quelle de mes page web. J'ai une réponse de chrome qui me dit "ce site est inaccessible ndd.com a mis trop de temps à répondre."

Mon log nginx est vide et voici le résultat d'un status:

root@emaxa ~ # service nginx status
● nginx.service - LSB: Stop/start nginx
   Loaded: loaded (/etc/init.d/nginx)
   Active: active (running) since Thu 2016-09-15 17:35:15 CEST; 14min ago
  Process: 25670 ExecStop=/etc/init.d/nginx stop (code=exited, status=0/SUCCESS)
  Process: 25678 ExecStart=/etc/init.d/nginx start (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/nginx.service
           ├─25707 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
           ├─25708 nginx: worker process
           ├─25710 nginx: worker process
           ├─25712 nginx: worker process
           ├─25713 nginx: worker process
           ├─25715 nginx: worker process
           ├─25717 nginx: worker process
           ├─25718 nginx: worker process
           └─25719 nginx: worker process

Sep 15 17:35:15 emaxa.me systemd[1]: Started LSB: Stop/start nginx.
root@emaxa ~ #

Au passage, mon hostname est 'emaxa.me' mais le domaine utilisé par mes fichiers de conf est 'shareyourlife.ovh' si ca peut intéresser.

Merci d'avance

xavier

Salut.

Déjà ce que tu peux faire c'est remettre le fichier comme avant et si sa re-fonctionnea alors cest ta modification qui fait plante le serveur..
et si c'est le cas poste la modification que tu as fait dans le topic..

Cordialement

nadrelaxe

C'est pas un modification mais création de fichier avec simplement un listen server_name et proxy pass.

Après supperission du fichier crée, et un restart toujours le même problème.

Je tiens à préciser que les logs (nginx, rutorrent et autres services du serveur) sont toujours vides et que les favicons des pages se chargent bien mais pas le reste.

Entre le moment ou j'ai testé pour la dernière fois et le moment où j'ai constaté le problème j'ai installé docker en suivant le tuto de xataz puis lancé un container nextcloud.

Depuis j'ai supprimé le container et arrêté l'instance docker.

Cela peut être la cause?

nadrelaxe

Après un test d'ouverture des ports via ce site il me dit que le 80 et le 443 sont fermés (ca m'étonne pas vraiment vu les symptômes 😉)

Du coup je checke mes règles iptables et j'obtiens ca:

root@emaxa /etc/nginx/sites-enabled # iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
fail2ban-nginx-badbots  tcp  --  anywhere             anywhere             multiport dports http,https
fail2ban-nginx-auth  tcp  --  anywhere             anywhere             multiport dports http,https
fail2ban-vsftpd  tcp  --  anywhere             anywhere             multiport dports ftp,ftp-data,ftps,ftps-data
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
DROP       all  --  anywhere             anywhere             ctstate INVALID
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
REJECT     all  --  anywhere             loopback/8           reject-with icmp-port-unreachable
ACCEPT     icmp --  anywhere             anywhere
ACCEPT     udp  --  anywhere             anywhere             udp spts:bootps:bootpc dpts:bootps:bootpc
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     udp  --  anywhere             anywhere             multiport dports isakmp,ipsec-nat-t
ACCEPT     udp  --  anywhere             anywhere             udp dpt:l2f policy match dir in pol ipsec
DROP       udp  --  anywhere             anywhere             udp dpt:l2f
DROP       all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
DOCKER-ISOLATION  all  --  anywhere             anywhere
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
DROP       all  --  anywhere             anywhere             ctstate INVALID
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  192.168.42.0/24      192.168.42.0/24
ACCEPT     all  --  anywhere             192.168.43.0/24      ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.43.0/24      anywhere
DROP       all  --  anywhere             anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain DOCKER (1 references)
target     prot opt source               destination

Chain DOCKER-ISOLATION (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Chain fail2ban-nginx-auth (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Chain fail2ban-nginx-badbots (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Chain fail2ban-ssh (1 references)
target     prot opt source               destination
REJECT     all  --  .                    anywhere             reject-with icmp-port-unreachable
RETURN     all  --  anywhere             anywhere

Chain fail2ban-vsftpd (1 references)
target     prot opt source               destination
RETURN     all  --  anywhere             anywhere

Et sincèrement j'ai jamais pris le temps de me pencher sur iptables donc j'ai du mal à décrypter.

xavier

Re

Donc serveur web est pas en cause.par contre au niveau docker je suis nul (j'ai fais mes premiers test hier 😛)

Oui peu être le problème vient du conteneur car il faut mapper les port : genre 80:15002 donc le port 80 vas sur le conteneur port 15002

donc oui il doit avoir encore un forward qui veut envoyer le 80 et 443 sur ton conteneur (qui existe plus)

la je sais pas comment réinitialisé les regle iptables docker

Moi sur mon serveur (j'ai pas de docker installer) je fais sa pour vider les regles

service fail2ban stop
# Vider les tables actuelles
iptables -t filter -F
 
# Vider les règles personnelles
iptables -t filter -X
#et apres on le relance 
service fail2ban start

a confirmé par un pro

nadrelaxe

Re,

effectivement c'est pas le serveur web.
En marge de ca j'ai ssuprimé toute trace de coker et ca ne suffit pas. Il dooit y avoir des règles persistantes.

xavier

Ce que j'ai vu de bizarre cest ces 2 lignes la

ACCEPT     all  --  192.168.42.0/24      192.168.42.0/24
ACCEPT     all  --  anywhere             192.168.43.0/24      ctstate RELATED,ESTABLISHED
ACCEPT     all  --  192.168.43.0/24      anywhere

tu es sur un reseau local (privée) ?

au pire un reboot du serveur normalement sa va remettre iptables a zero (sauf les règles de fail2ban)

nadrelaxe

Non pourtant mais je suis d'accord avec toi ces deux lignes ne me paraissent pas naturelles.

Je suis dans un datacenter donc normalement aucune raison de voir ca.

Avec mon partitionnement en LVM j'ai peur que le reboot ne fonctionne pas (j'ai déjà eu des problèmes la dessus).

Je vais essayer sinon redémarrage à zéro.

xataz

Salut,

Je penserais pour une règle IPtables, ou alors un blocage fail2ban, mais ça me parait étrange.
S'il y avais un problème coté serveur web, tu aurais une erreur 503 je pense.

Pour réinitialiser les règles iptables, tu peux faire ceci :

iptables -F
iptables -X

Autrement pour les règles docker, elle ne devrais en aucun cas bloquer ton serveur, le chain DOCKER servant à la redirection des ports, et le chaine DOCKER-ISOLATION, à bloquer les communications entre les réseaux docker.
Ici tu n'as en fait aucune règles niveau docker.

nadrelaxe

Bonjour,

effectivement un reset des tables et un restart a suffit à remettre le serveur d'aplomb.
Mais qu'est ce qui aurait pu causer ce problème? Car je ne souhaite pas que ce recommence

Merci encore à vous!

xavier

Salut

Très simple si souhaite pas que ce recommence , ne pas faire de test sur un serveur en production

si le problème venais bien de docker.(enfin docker fonctionne très bien mais je pense plutôt toi qui a du faire une fausse manip quand ta crée une règles pour nextcloud )

ps: moi pour docker(ou tout autres tests) j'installe une machine virtuel cher moi pour testé (j'utilise VirtualBox)

xavier

tu peux faire un

iptables -L

(voir si le réseau local est toujours la)

nadrelaxe

Oui je pense que je vais procéder comme ca aussi, docker fournisse tout pour faire la vm avec virtual box donc c'est super simple.J'y penserai à l'avenir.

Merci