~50% packet loss sur serveur debian

harkness · 21 déc. 2017, 01:18

Bonjour,

J’ai un serveur debian chez moi qui me sert pour openvpn, plex, owncloud, gitlab…

Et depuis quelques jours j’ai une connexion qui marche par intermittence et si je fais un ping de mon IP publique j’ai environ 50% de packet loss(que ce soit chez moi ou depuis un autre réseau).

Par contre quand je suis en local je peux ping mon serveur sur son IP local sans problème, mais je ne peux pas accéder a internet pendant un certain temps. Si j’interdis l’accès a internet a mon serveur depuis l’application Android de mon routeur(Xiaomi Mi R3P) la aucun problème d’internet et je peux ping mon nom de domaine sans timeout.

J’avais déjà eu le problème y a quelque mois, mais croyant que c’était juste un serveur mal configurer, je me suis contenté de faire un formatage pour recommencer sur des bases propres et cela avais résolus le problème.

J’ai des connaissances très limitées en réseau donc si quelqu’un a une idée je suis preneur.

Voici ma table de routage si ca peux aider :

Code : Tout sélectionner

route

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
default         XiaoQiang       0.0.0.0         UG    0      0        0 enp3s0
10.8.0.0        0.0.0.0         255.255.255.0   U     0      0        0 tun0
172.17.0.0      0.0.0.0         255.255.0.0     U     0      0        0 docker0
192.168.31.0    0.0.0.0         255.255.255.0   U     0      0        0 enp3s0

Et ifconfig :

Code : Tout sélectionner

ifconfig -a

docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 0.0.0.0
        inet6 fe80::42:54ff:fe45:7d7e  prefixlen 64  scopeid 0x20<link>
        ether 02:42:54:45:7d:7e  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 16271  bytes 1550803 (1.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

enp3s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.31.86  netmask 255.255.255.0  broadcast 192.168.31.255
        inet6 fe80::e2d5:5eff:fe16:3222  prefixlen 64  scopeid 0x20<link>
        ether e0:d5:5e:16:32:22  txqueuelen 1000  (Ethernet)
        RX packets 560099  bytes 69385245 (66.1 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1072525825  bytes 68450342967 (63.7 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1  (Local Loopback)
        RX packets 1471841  bytes 2756231049 (2.5 GiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1471841  bytes 2756231049 (2.5 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

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
        inet6 fe80::f58e:a0fe:3829:c035  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 100  (UNSPEC)
        RX packets 15080  bytes 1583530 (1.5 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 21107  bytes 21267160 (20.2 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Merci d’avance pour vos réponses

21 déc. 2017, 17:04

Salut et bienvenu sur le fofo,

La machine fait office de passerelle Internet ? Quelle est la topologie réseau exactement ? Il y a une Box entre la machine Debian et Internet ?
tun0 ? Il y a un tunnel vpn ou c'est pour un autre usage ?
Que raconte iptables -S et iptables-save ?

harkness · 21 déc. 2017, 18:56

Bonjour,

Tout d’abord merci pour ta réponse ^^
La machine n’est pas censée servir de passerelle, c’est pour ça que je me demande comment elle peut avoir une influence sur tout mon réseau local(je ne peux pas accéder a internet fréquemment), elle sert juste pour des services basiques et comme serveur openvpn quand j’ai besoin d’accéder a mon réseau local a distance.

J’ai une box 4k SFR qui est réglé en mode bridge, dessus j’ai mon routeur(Xiaomi Mi R3P) et sur ce routeur j’ai juste le serveur(GIGABYTE Barebone Brix Bace 3150 ) brancher en ethernet ainsi que mon ordi portable en ethernet quand je suis sur mon bureau. Et tun0 c’est l’interface pour openvpn il me semble.

Pour iptable -S :

Code : Tout sélectionner

-P INPUT DROP
-P FORWARD DROP
-P OUTPUT ACCEPT
-N DOCKER
-N DOCKER-ISOLATION
-N f2b-sshd
-N ufw-after-forward
-N ufw-after-input
-N ufw-after-logging-forward
-N ufw-after-logging-input
-N ufw-after-logging-output
-N ufw-after-output
-N ufw-before-forward
-N ufw-before-input
-N ufw-before-logging-forward
-N ufw-before-logging-input
-N ufw-before-logging-output
-N ufw-before-output
-N ufw-logging-allow
-N ufw-logging-deny
-N ufw-not-local
-N ufw-reject-forward
-N ufw-reject-input
-N ufw-reject-output
-N ufw-skip-to-policy-forward
-N ufw-skip-to-policy-input
-N ufw-skip-to-policy-output
-N ufw-track-forward
-N ufw-track-input
-N ufw-track-output
-N ufw-user-forward
-N ufw-user-input
-N ufw-user-limit
-N ufw-user-limit-accept
-N ufw-user-logging-forward
-N ufw-user-logging-input
-N ufw-user-logging-output
-N ufw-user-output
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j DOCKER-ISOLATION
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A DOCKER -d 172.17.0.3/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 9980 -j ACCEPT
-A DOCKER-ISOLATION -j RETURN
-A f2b-sshd -s 61.177.172.66/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 22 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 443 -j DROP
-A ufw-user-input -p udp -m udp --dport 443 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 1900 -j DROP
-A ufw-user-input -p udp -m udp --dport 1900 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 80 -j DROP
-A ufw-user-input -p udp -m udp --dport 80 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 32400 -j DROP
-A ufw-user-input -p udp -m udp --dport 32400 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 5000 -j DROP
-A ufw-user-input -p udp -m udp --dport 5000 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 6881 -j DROP
-A ufw-user-input -p udp -m udp --dport 6881 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 3000 -j DROP
-A ufw-user-input -p udp -m udp --dport 3000 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 3001 -j DROP
-A ufw-user-input -p udp -m udp --dport 3001 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 8080 -j DROP
-A ufw-user-input -p udp -m udp --dport 8080 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 8181 -j DROP
-A ufw-user-input -p udp -m udp --dport 8181 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 8983 -j DROP
-A ufw-user-input -p udp -m udp --dport 8983 -j DROP
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT

et pour iptable-save

Code : Tout sélectionner

# Generated by iptables-save v1.6.0 on Thu Dec 21 18:44:15 2017
*nat
:PREROUTING ACCEPT [5209:364931]
:INPUT ACCEPT [44:6339]
:OUTPUT ACCEPT [11752058:565032396]
:POSTROUTING ACCEPT [11751252:564734124]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 192.168.31.86
-A POSTROUTING -s 172.17.0.3/32 -d 172.17.0.3/32 -p tcp -m tcp --dport 9980 -j MASQUERADE
-A DOCKER -i docker0 -j RETURN
-A DOCKER -d 127.0.0.1/32 ! -i docker0 -p tcp -m tcp --dport 9980 -j DNAT --to-destination 172.17.0.3:9980
COMMIT
# Completed on Thu Dec 21 18:44:15 2017
# Generated by iptables-save v1.6.0 on Thu Dec 21 18:44:15 2017
*filter
:INPUT DROP [34:4526]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [48:4032]
:DOCKER - [0:0]
:DOCKER-ISOLATION - [0:0]
:f2b-sshd - [0:0]
:ufw-after-forward - [0:0]
:ufw-after-input - [0:0]
:ufw-after-logging-forward - [0:0]
:ufw-after-logging-input - [0:0]
:ufw-after-logging-output - [0:0]
:ufw-after-output - [0:0]
:ufw-before-forward - [0:0]
:ufw-before-input - [0:0]
:ufw-before-logging-forward - [0:0]
:ufw-before-logging-input - [0:0]
:ufw-before-logging-output - [0:0]
:ufw-before-output - [0:0]
:ufw-logging-allow - [0:0]
:ufw-logging-deny - [0:0]
:ufw-not-local - [0:0]
:ufw-reject-forward - [0:0]
:ufw-reject-input - [0:0]
:ufw-reject-output - [0:0]
:ufw-skip-to-policy-forward - [0:0]
:ufw-skip-to-policy-input - [0:0]
:ufw-skip-to-policy-output - [0:0]
:ufw-track-forward - [0:0]
:ufw-track-input - [0:0]
:ufw-track-output - [0:0]
:ufw-user-forward - [0:0]
:ufw-user-input - [0:0]
:ufw-user-limit - [0:0]
:ufw-user-limit-accept - [0:0]
:ufw-user-logging-forward - [0:0]
:ufw-user-logging-input - [0:0]
:ufw-user-logging-output - [0:0]
:ufw-user-output - [0:0]
-A INPUT -p tcp -m multiport --dports 22 -j f2b-sshd
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -j ufw-before-logging-input
-A INPUT -j ufw-before-input
-A INPUT -j ufw-after-input
-A INPUT -j ufw-after-logging-input
-A INPUT -j ufw-reject-input
-A INPUT -j ufw-track-input
-A FORWARD -j DOCKER-ISOLATION
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -j ufw-before-logging-forward
-A FORWARD -j ufw-before-forward
-A FORWARD -j ufw-after-forward
-A FORWARD -j ufw-after-logging-forward
-A FORWARD -j ufw-reject-forward
-A FORWARD -j ufw-track-forward
-A OUTPUT -j ufw-before-logging-output
-A OUTPUT -j ufw-before-output
-A OUTPUT -j ufw-after-output
-A OUTPUT -j ufw-after-logging-output
-A OUTPUT -j ufw-reject-output
-A OUTPUT -j ufw-track-output
-A DOCKER -d 172.17.0.3/32 ! -i docker0 -o docker0 -p tcp -m tcp --dport 9980 -j ACCEPT
-A DOCKER-ISOLATION -j RETURN
-A f2b-sshd -s 61.177.172.66/32 -j REJECT --reject-with icmp-port-unreachable
-A f2b-sshd -j RETURN
-A ufw-after-input -p udp -m udp --dport 137 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 138 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 139 -j ufw-skip-to-policy-input
-A ufw-after-input -p tcp -m tcp --dport 445 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 67 -j ufw-skip-to-policy-input
-A ufw-after-input -p udp -m udp --dport 68 -j ufw-skip-to-policy-input
-A ufw-after-input -m addrtype --dst-type BROADCAST -j ufw-skip-to-policy-input
-A ufw-after-logging-forward -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-after-logging-input -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-before-forward -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-forward -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-forward -j ufw-user-forward
-A ufw-before-input -i lo -j ACCEPT
-A ufw-before-input -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-input -m conntrack --ctstate INVALID -j ufw-logging-deny
-A ufw-before-input -m conntrack --ctstate INVALID -j DROP
-A ufw-before-input -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A ufw-before-input -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A ufw-before-input -p udp -m udp --sport 67 --dport 68 -j ACCEPT
-A ufw-before-input -j ufw-not-local
-A ufw-before-input -d 224.0.0.251/32 -p udp -m udp --dport 5353 -j ACCEPT
-A ufw-before-input -d 239.255.255.250/32 -p udp -m udp --dport 1900 -j ACCEPT
-A ufw-before-input -j ufw-user-input
-A ufw-before-output -o lo -j ACCEPT
-A ufw-before-output -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A ufw-before-output -j ufw-user-output
-A ufw-logging-allow -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW ALLOW] "
-A ufw-logging-deny -m conntrack --ctstate INVALID -m limit --limit 3/min --limit-burst 10 -j RETURN
-A ufw-logging-deny -m limit --limit 3/min --limit-burst 10 -j LOG --log-prefix "[UFW BLOCK] "
-A ufw-not-local -m addrtype --dst-type LOCAL -j RETURN
-A ufw-not-local -m addrtype --dst-type MULTICAST -j RETURN
-A ufw-not-local -m addrtype --dst-type BROADCAST -j RETURN
-A ufw-not-local -m limit --limit 3/min --limit-burst 10 -j ufw-logging-deny
-A ufw-not-local -j DROP
-A ufw-skip-to-policy-forward -j DROP
-A ufw-skip-to-policy-input -j DROP
-A ufw-skip-to-policy-output -j ACCEPT
-A ufw-track-output -p tcp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-track-output -p udp -m conntrack --ctstate NEW -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 22 -j ACCEPT
-A ufw-user-input -p udp -m udp --dport 22 -j ACCEPT
-A ufw-user-input -p tcp -m tcp --dport 443 -j DROP
-A ufw-user-input -p udp -m udp --dport 443 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 1900 -j DROP
-A ufw-user-input -p udp -m udp --dport 1900 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 80 -j DROP
-A ufw-user-input -p udp -m udp --dport 80 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 32400 -j DROP
-A ufw-user-input -p udp -m udp --dport 32400 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 5000 -j DROP
-A ufw-user-input -p udp -m udp --dport 5000 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 6881 -j DROP
-A ufw-user-input -p udp -m udp --dport 6881 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 3000 -j DROP
-A ufw-user-input -p udp -m udp --dport 3000 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 3001 -j DROP
-A ufw-user-input -p udp -m udp --dport 3001 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 8080 -j DROP
-A ufw-user-input -p udp -m udp --dport 8080 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 8181 -j DROP
-A ufw-user-input -p udp -m udp --dport 8181 -j DROP
-A ufw-user-input -p tcp -m tcp --dport 8983 -j DROP
-A ufw-user-input -p udp -m udp --dport 8983 -j DROP
-A ufw-user-limit -m limit --limit 3/min -j LOG --log-prefix "[UFW LIMIT BLOCK] "
-A ufw-user-limit -j REJECT --reject-with icmp-port-unreachable
-A ufw-user-limit-accept -j ACCEPT
COMMIT
# Completed on Thu Dec 21 18:44:15 2017

Après moi j'utilise ufw comme pare-feu et j'ai essayé de tout bloquer sauf le port ssh mais ça ne change rien au problème

Code : Tout sélectionner

ufw status

Code : Tout sélectionner

Status: active

To                         Action      From
--                         ------      ----
22                         ALLOW       Anywhere
443                        DENY        Anywhere
1900                       DENY        Anywhere
80                         DENY        Anywhere
32400                      DENY        Anywhere
5000                       DENY        Anywhere
6881                       DENY        Anywhere
3000                       DENY        Anywhere
3001                       DENY        Anywhere
8080                       DENY        Anywhere
8181                       DENY        Anywhere
8983                       DENY        Anywhere
22 (v6)                    ALLOW       Anywhere (v6)
443 (v6)                   DENY        Anywhere (v6)
1900 (v6)                  DENY        Anywhere (v6)
80 (v6)                    DENY        Anywhere (v6)
32400 (v6)                 DENY        Anywhere (v6)
5000 (v6)                  DENY        Anywhere (v6)
6881 (v6)                  DENY        Anywhere (v6)
3000 (v6)                  DENY        Anywhere (v6)
3001 (v6)                  DENY        Anywhere (v6)
8080 (v6)                  DENY        Anywhere (v6)
8181 (v6)                  DENY        Anywhere (v6)
8983 (v6)                  DENY        Anywhere (v6)

22 déc. 2017, 06:09

Salut,

J'ai déjà été emmerdé par un parefeu mal fait et un openvpn: La machine ne répondait plus sur l'interface publique...
Je commencerais pas désactiver le parefeu en ne conservant que les règles nécessaires (Masquerade, forwarding, etc.).
Après tout le serveur n'est pas directement connecté à Internet, tu ne risque pas grand chose (ton LAN est bien protégé ?).

Si c'est possible regarde les logs au moment ou le serveur n'a plus accès à Internet, tu y trouvera surement des pistes (paquets bloqués, VPN qui mouline, etc.).

Je n'utilise pas (et je ne connais pas) UFW donc de ce côté je ne serais pas capable d'une expertise précise...
Mais je vois beaucoup de DROP et DENY, tu as surement abusé...

22 déc. 2017, 16:33

Si je comprends bien, l'interface ethernet du serveur a une adresse IP privée et la box est en bridge, donc c'est le routeur qui a l'adresse IP publique ?
Donc quand tu pingues l'adresse IP publique, en fait tu pingues le routeur, non ?
Ou alors le routeur est configuré pour rediriger certains (redirection de port) voire tous ("DMZ") les flux entrants vers l'adresse IP privée du serveur ?

harkness a écrit : Par contre quand je suis en local je peux ping mon serveur sur son IP local sans problème

Quand tu pingues l'adresse IP privée du serveur, tu pingues directement le serveur, pas le routeur.

harkness a écrit : mais je ne peux pas accéder a internet pendant un certain temps.

Comment ça "pas accéder à internet" ?
Pendant combien de temps ?
Et après, tu peux ?

harkness a écrit : Si j’interdis l’accès a internet a mon serveur depuis l’application Android de mon routeur(Xiaomi Mi R3P)

C'est-à-dire ?
Tu veux dire interdire l'accès à ton serveur depuis internet ?

harkness a écrit : aucun problème d’internet et je peux ping mon nom de domaine sans timeout.

On ne pingue pas un nom de domaine mais une adresse IP. On résoud un nom de domaine.
Donc dans le cas précédent, qu'est-ce qui marche mal ? La résolution du nom ou le ping de l'adresse IP ?

harkness · 22 déc. 2017, 21:57

Bonjour ^^

J'ai déjà été emmerdé par un parefeu mal fait et un openvpn: La machine ne répondait plus sur l'interface publique...
Je commencerais pas désactiver le parefeu en ne conservant que les règles nécessaires (Masquerade, forwarding, etc.).
Après tout le serveur n'est pas directement connecté à Internet, tu ne risque pas grand chose (ton LAN est bien protégé ?).

Si c'est possible regarde les logs au moment ou le serveur n'a plus accès à Internet, tu y trouvera surement des pistes (paquets bloqués, VPN qui mouline, etc.).

Je n'utilise pas (et je ne connais pas) UFW donc de ce côté je ne serais pas capable d'une expertise précise...
Mais je vois beaucoup de DROP et DENY, tu as surement abusé...

D'accord merci lol j'essayerais ça quand je serais de retour chez moi, mon serveur est totalement inaccessible actuellement et je peux ping le routeur sans problème(ce qui veut probablement dire que le serveur s'est éteint puisque c’est le serveur qui provoque le problème de ping).

Si je comprends bien, l'interface ethernet du serveur a une adresse IP privée et la box est en bridge, donc c'est le routeur qui a l'adresse IP publique ?
Donc quand tu pingues l'adresse IP publique, en fait tu pingues le routeur, non ?
Ou alors le routeur est configuré pour rediriger certains (redirection de port) voire tous ("DMZ") les flux entrants vers l'adresse IP privée du serveur ?

Effectivement c'est mon routeur qui a l'IP publique et j'ai une redirection de port vers le serveur pour ceux dont j'ai besoin 22,80,443... Je croyais que le ping était transmis au serveur, mais tu as raison c'est sûrement juste le routeur qui doit être ping.

Comment ça "pas accéder à internet" ?
Pendant combien de temps ?
Et après, tu peux ?

Bah en faite je viens de comprendre que c'est probablement mon routeur qui pose pose problème, car quand je veux ping mon IP publique depuis une autre connexion et que ça timeout, je n'ai pas non plus internet chez moi pendant ce laps de temps, ce qui fait que j'ai internet par intermittence.

C'est-à-dire ?
Tu veux dire interdire l'accès à ton serveur depuis internet ?

Je veux dire depuis les paramètres de mon routeur d'interdire l'accès à internet au serveur.

On ne pingue pas un nom de domaine mais une adresse IP. On résoud un nom de domaine.
Donc dans le cas précédent, qu'est-ce qui marche mal ? La résolution du nom ou le ping de l'adresse IP ?

Pardon je me suis mal exprimé et c'est bien le ping de l'adresse IP qui timeout, la résolution du nom de domaine ne pose aucun probléme ^^

Donc je pense que c'est mon serveur qui fait bugger mon routeur je ne sais comment et cela affecte aussi les autres appareils connecter au même routeur qui n’ont plus accès a internet pendant le laps de temps ou le routeur ne répond plus. Que ce soit au ping extérieur ou aux requêtes internet faites pas les appareils du réseau local. Car je rappelle, je n’ai aucun problème de routeur quand mon serveur n’est pas connecté à internet.

23 déc. 2017, 00:55

harkness a écrit : Je veux dire depuis les paramètres de mon routeur d'interdire l'accès à internet au serveur.

Je ne comprends toujours pas ce que cela signifie concrètement. Peux-tu expliquer l'effet que c'est censé avoir ? Empêcher les connexions sortantes du serveur vers internet ou les connexions entrantes d'internet vers le serveur, ou les deux ?

harkness · 23 déc. 2017, 01:55

Concrètement ça empêche juste toute connections sortante et entrantes du serveur comme indiquer sur le screen ^^

23 déc. 2017, 10:07

Quand tu écris "50% packet loss", c'est un ping sur deux qui répond ou bien N à la suite sans aucune réponse puis N à la suite qui obtiennent tous une réponse ?

Je suis d'accord, c'est probablement l'activité du serveur qui perturbe et sature le routeur. Il faudrait surveiller son trafic réseau pour essayer d'en savoir plus.

harkness · 26 déc. 2017, 01:26

Du coup, je suis rentré chez moi, mais j'avoue que je ne sais pas trop quoi faire.

Mais chose étrange quand je suis en ssh depuis l'IP local et que mon routeur ne répond plus, le serveur en ssh est toujours accessible, je peux taper des commandes et tout, mais c'est très lent, alors que la connexion est directe entre le serveur et l'ordi(qui est en Ethernet).
J'ai regardé les log de syslog, mais rien d'anormal quand les lag surviennent, je ne sais pas quel log regarder en particulier.

Quand au routeur son interface web est également inaccessible pendant les timeout du ping, mais les stats d'utilisation du routeur sont normaux environ 5% d'utilisation de la RAM et 20% du proc pas de chute ou de hausse quand il devient inaccessible.

J'ai aussi désactivé le pare-feu avec la commande :

Code : Tout sélectionner

ufw disable && iptables -F && iptables -X && iptables -t nat -F && iptables -t nat -X && iptables -t mangle -F && iptables -t mangle -X && iptables -P INPUT ACCEPT && iptables -P OUTPUT ACCEPT && iptables -P FORWARD ACCEPT

Mais je n’ai pas l'impression que ça a changé quelque chose. Par contre quand je suis rentré chez moi, le serveur était toujours inaccessible, mais depuis que je l'ai débrancher/rebrancher j'ai beaucoup moins de perte de paquet, le problème est un peu moins fréquent, la en faisant un ping de 20min j'ai seulement 10% de paquet loss. Et a savoir que ce problème était a la base occasionnelle jusqu'a devenir très régulier(et atteindre ~50% de paquet loss) donc j'avoue que je vois vraiment pas d'ou vient le problème :/

26 déc. 2017, 13:44

La première chose à regarder quand une machine rame, c'est l'occupation des ressources système : CPU, mémoire, swap, activité disque...

Ensuite, qu'entends-tu exactement par "je peux taper des commandes et tout, mais c'est très lent" ?
Est-ce c'est la frappe des commandes ou l'affichage de leur sortie qui laggue ou leur exécution ? (à tester avec une commande qui prend du temps à s'exécuter mais n'affiche pas grand-chose par exemple)

Est-ce que c'est pareil avec une session ouverte sur une console physique et non par SSH ?

La corrélation avec l'inaccessibilité du routeur et d'internet fait vraiment penser à quelque chose lié au réseau. Parmi les hypothèses possibles, je pense soit à une saturation du serveur, du routeur et de l'accès internet causé par des communications excessives du serveur avec l'extérieur (entrantes ou sortantes ? normales ou malveillantes ?) ; ou bien à une anomalie du serveur au niveau ethernet qui perturberait aussi le routeur, mais dans ce cas je ne vois pas trop en quoi couper l'accès internet du serveur supprimerait l'anomalie.

Qu'as-tu "branché/débranché" exactement en revenant chez toi ? Le câble réseau du serveur ? Son alimentation ?

As-tu la possibilité d'observer le trafic réseau du serveur lorsque le problème se produit ?

26 déc. 2017, 13:58

Salut,
La même IP utilisée deux fois sur le LAN pourrait aussi causer ce comportement erratiques, non ?

26 déc. 2017, 14:37

J'en doute. L'adresse IP de quelle machine ?

Si une machine avait la même adresse IP que le serveur, il y aurait deux machines répondant à la même adresse. Un ping lancé depuis une autre machine du LAN n'aboutirait pas forcément sur le serveur mais c'est la machine avec l'adresse en doublon qui répondrait, donc pas de perte de paquets.

Si une machine avait la même adresse IP que le routeur, cela pourrait effectivement impacter la connectivité internet des machines du LAN puisqu'une partie des paquets envoyés depuis le LAN destinés au routeur aboutiraient sur l'autre machine en doublon mais cela n'impacterait pas la connectivité internet du routeur lui-même je ne vois pas en quoi la déconnexion du serveur impacterait la connectivité internet des autres machines du LAN.

Si une machine avait la même adresse IP que le poste client du LAN, celle-ci aurait des difficultés à communiquer avec le serveur, le routeur et internet puisqu'une partie des paquets qui lui sont destinés aboutiraient sur la machine avec l'adresse en doublon. Mais là encore, je ne vois pas en quoi cela impacterait la connectivité internet du serveur et du routeur.

26 déc. 2017, 14:41

Ok,
Désolé pour l'idée non pertinente et la digression... mais merci pour l'explication. :-)

26 déc. 2017, 14:48

L'idée était pertinente, sinon je n'aurais pas eu besoin d'écrire tout ce laïus pour la réfuter. Et je peux avoir oublié un cas particulier où elle serait avérée.

harkness · 27 déc. 2017, 00:32

Quand je disais que tout était lent, je parlais de l'affichage en ssh, c'est-à-dire que quand je taper sur le clavier il y avait énormément de latence (1 a 3s) avant que ce je j'écrive s'affiche.
Avec un accès physique, il n'y a pas de lag.
En rentrant chez moi j'ai débranché l'alimentation puis rebrancher et le problème était moins présent, mais il est bien evidament revenu, mais avec des différences que je ne comprends pas.

Avant mon routeur était injoignable le temps ou je n’avais pas internet, mais je pouvais comme même ping mon serveur depuis son ip local.
Maintenant pendant les périodes sans internet, je peux depuis mon ordi connecter au réseau du routeur, ping l'ip locale du routeur et aussi son ip publique MAIS je ne peux plus ping mon serveur sur son ip locale. Et si j'essaye de ping mon routeur depuis un réseau extérieur pendant le problème d'internet ça timeout. Mon serveur lui ne peut pas ping mon routeur pendant le laps de temps ou je n’ai pas internet par contre il peux ping mon ordi portable(alors que mon ordi timeout si il ping le serveur Oo). Bon c'est absolument pas claire, mais pour résumer avant je pouvais ping mon serveur en locale, mais pas mon routeur, et maintenant c'est l'inverse je peux ping mon routeur en local, mais pas mon serveur, donc je ne comprends pas comment ça peut affecter ma connexion internet si c'est juste le serveur qui ne répond plus pendant un temps :/

Donc pour simplifier durant les problèmes de connection, ou le ping de mon routeur depuis l'exterieur timeout :

ping tel en 4G -> ip publique du routeur = timeout

ping ordi -> routeur = ok
ping ordi -> serveur = timeout

ping serveur -> routeur = timeout
ping serveur -> ordi = ok

Quand aux ressources system pas de changement pendant les problèmes de connexion(j'ai vérifié avec htop avec un accès physique au serveur), mais deux choses étranges.
Il y a 2 processus qui consomme anormalement beaucoup de ressources.

D'abord un processus s'appelant "ipconfig eth0" qui prenait ~100% du proc, alors que je n'ai aucune interface réseau s'appelant eth0 oO. Je l'ai kill et même après plusieurs redémarrages ce process n'est jamais réapparu, mais ça reste bizarre.

Et le deuxième s'appelle wipefs et il prend en moyenne 200% du proc d'apres htop, je peux le kill mais ça ne change rien au problème de connexion et il se relance au redémarrage. Je mets un screen de la commande htop si ça peut aider :

Et j'ai bien vérifié au cas ou chaque appareil connecter au réseau a bien une IP locale différente ^^

27 déc. 2017, 20:37

Le lag du shell en SSH mais pas en console locale indique que le lag vient probablement du réseau, pas de la charge du système lui-même. Tu as regardé ce qu'affiche netstat concernant les sockets réseau ?

ipconfig est un client DHCP minimaliste inclus dans le paquet klibc-utils. Il est intégré dans l'initramfs. Peut-être sert-il à configurer le réseau lorsque la racine à monter est en NFS.

Je ne vois pas non plus comment les processus tête de la liste que sont id et wipefs peuvent d'une part occuper autant de CPU et d'autre part tourner depuis aussi longtemps. La commande id sert à afficher des informations sur un utilisateur ou un groupe. La commande wipefs sert à détecter et/ou effacer les signatures de méta-données des disques, partitions, et autres volumes. Ces deux programmes ne sont pas censés rester résidents, leur temps d'exécution est normalement très court.

Ton serveur ne serait pas vérolé, et aurait par moments une activité internet anormale, saturant la connexion internet et sa propre connexion au réseau local ?

harkness · 27 déc. 2017, 23:14

Je pense avoir trouvé d'où vient le problème. En surveillant le trafic réseau du serveur avec tshark je peux voir que mon serveur fait des requêtes en boucle a la même IP ce qui fait saturer mon réseau. Voici un exemple de que j'ai en boucle :

Code : Tout sélectionner

112098 25.271334889 192.168.31.86 → 101.132.103.234 TCP 62 [TCP Port numbers reused] 21079 → 8611 [SYN] Seq=0 Win=60214 Len=8

D'après https://www.countryipblocks.net/search_ ... 32.103.234 ça serait une IP chinoise, je ne sais pas quoi elle correspond, ni si la requête est sortante ou entrante de mon serveur. J'ai essayé de bloquer les IP 101.132.0.0 a 101.132.255.255 avec iptables mais ça ne fonctionne pas, je connais pas trop iptables(j'utilise ufw d'habitude qui est une sorte de front simplifie pour iptables, et que j'ai désactivé). Voici le résultat de la commande iptables -L :

Code : Tout sélectionner

Chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn
ACCEPT     udp  --  anywhere             anywhere             udp dpt:openvpn
DROP       all  --  101.132.0.0/16       anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
DOCKER-ISOLATION  all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
DOCKER     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere
ACCEPT     all  --  10.8.0.0/24          anywhere
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  10.8.0.0/24          anywhere
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
DROP       all  --  101.132.0.0/16       anywhere

Chain DOCKER (1 references)
target     prot opt source               destination
ACCEPT     tcp  --  anywhere             172.17.0.2           tcp dpt:9980

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

27 déc. 2017, 23:24

Le format de sortie d'iptables -L est incomplet et illisible. Utilise plutôt iptables-save.
On peut quand même voir que ta règle bloque la plage d'adresses en tant que source dans les paquets sortants, ce qui n'existe pas. L'adresse source des paquets sortants, c'est celle de ta machine. Il faut bloquer l'adresse destination.

Code : Tout sélectionner

iptables -I OUTPUT -d 101.132.0.0/16 -j DROP

harkness · 28 déc. 2017, 12:25

Ah oui en effet merci !
La commande a bien fonctionné, mais même après ça, une autre ip prenait le relais (genre 120.78.227.53 ou 47.96.187.251 toujours des ip chinoise).
J'ai essayé de bloquer le port 62(sur lequel toutes les requêtes sont faites) avec "iptables -A OUTPUT -p tcp -m tcp --dport 62 -j DROP" mais ça ne bloque rien.
Voici mon iptables-saves :

Code : Tout sélectionner

# Generated by iptables-save v1.6.0 on Thu Dec 28 12:20:18 2017
*mangle
:PREROUTING ACCEPT [58702:7622821]
:INPUT ACCEPT [58672:7610975]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [4178593:204712812]
:POSTROUTING ACCEPT [4179069:204763310]
COMMIT
# Completed on Thu Dec 28 12:20:18 2017
# Generated by iptables-save v1.6.0 on Thu Dec 28 12:20:18 2017
*filter
:INPUT ACCEPT [1044:495560]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1017:461669]
:DOCKER - [0:0]
:DOCKER-ISOLATION - [0:0]
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A INPUT -p udp -m udp --dport 1194 -j ACCEPT
-A FORWARD -j DOCKER-ISOLATION
-A FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -o docker0 -j DOCKER
-A FORWARD -i docker0 ! -o docker0 -j ACCEPT
-A FORWARD -i docker0 -o docker0 -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A OUTPUT -d 101.132.0.0/16 -j DROP
-A OUTPUT -p tcp -m tcp --dport 62 -j DROP
-A DOCKER-ISOLATION -j RETURN
COMMIT
# Completed on Thu Dec 28 12:20:18 2017
# Generated by iptables-save v1.6.0 on Thu Dec 28 12:20:18 2017
*nat
:PREROUTING ACCEPT [5:614]
:INPUT ACCEPT [5:614]
:OUTPUT ACCEPT [143:12650]
:POSTROUTING ACCEPT [137:10430]
:DOCKER - [0:0]
-A PREROUTING -m addrtype --dst-type LOCAL -j DOCKER
-A OUTPUT ! -d 127.0.0.0/8 -m addrtype --dst-type LOCAL -j DOCKER
-A POSTROUTING -s 172.17.0.0/16 ! -o docker0 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 192.168.31.86
-A POSTROUTING -s 172.17.0.8/32 -d 172.17.0.8/32 -p tcp -m tcp --dport 9980 -j MASQUERADE
-A POSTROUTING -s 10.8.0.0/24 ! -d 10.8.0.0/24 -j SNAT --to-source 192.168.31.86
-A DOCKER -i docker0 -j RETURN
COMMIT
# Completed on Thu Dec 28 12:20:18 2017

Y a-t-il un moyen de savoir d'où viennent toutes ces requêtes ? Genre quels script ou programme, car si j'ai bien compris les requêtes sont sortante et ne viennent pas de l'extérieur.