Ubuntu server met Nginx Connection timeout

[HellStorm666]

Beste mede-Tweakers,

Enige tijd geleden overgestapt van Ubuntu server 14.04LT naar Ubuntu 15.04 en daarna 15.10.
De toenmalige webserver draaide Apache en had een hoop onoverzichtelijkheid bij zich.

Dit was het moment voor mij op over te gaan naar Nginx.
Alles verliep redelijk goed. Systeem draait nu 15.10 met nginx 1.9.5 met http2.
Haal een A+ bij SSLlabs en response-time is ook ongeveer gehalveerd.

Om de uptime in de gate te houden een account bij uptime robot aangemaakt. deze check een pagina op de website elke 5 minuten.

En daar begint het probleem.
Met enige regelmaat is de website dus niet bereikbaar.
"Connection Timeout" is de foutmelding.
Log van de firewall laat zien dat de verbinding gewoon doorgelaten wordt.
Log van nginx laat ook geen fouten zien.
Ik heb in totaal 10 services die door uptime robot in de gaten worden gehouden.
Een site met php, een site zonder php, de WAN kant, een VPN server, enz.
De website met php en de site zonder php zijn beide altijd tegelijk niet bereikbaar. en komen ook beide weer tegelijk terug.

Hier een log van alleen van vandaag van uptime-robot

code:

Up  V3  27-10-2015 16:24    OK  0 hrs, 6 mins
Down    V3  27-10-2015 16:23    Connection Timeout  0 hrs, 0 mins
Up  V3  27-10-2015 15:57    OK  0 hrs, 25 mins
Up  website 27-10-2015 15:57    OK  0 hrs, 33 mins
Down    V3  27-10-2015 15:56    Connection Timeout  0 hrs, 1 mins
Down    website 27-10-2015 15:56    Connection Timeout  0 hrs, 1 mins
Up  V3  27-10-2015 9:42 OK  6 hrs, 13 mins
Down    V3  27-10-2015 9:42 Connection Timeout  0 hrs, 0 mins
Up  website 27-10-2015 7:30 OK  8 hrs, 26 mins
Down    website 27-10-2015 7:29 Connection Timeout  0 hrs, 0 mins
Up  V3  27-10-2015 7:09 OK  2 hrs, 32 mins
Down    V3  27-10-2015 7:08 Connection Timeout  0 hrs, 0 mins
Up  website 27-10-2015 6:48 OK  0 hrs, 40 mins
Up  V3  27-10-2015 6:47 OK  0 hrs, 20 mins
Down    V3  27-10-2015 3:13 Connection Timeout  3 hrs, 34 mins
Down    website 27-10-2015 3:12 Connection Timeout  3 hrs, 36 mins
Up  V3  27-10-2015 2:39 OK  0 hrs, 34 mins
Up  website 27-10-2015 2:39 OK  0 hrs, 33 mins
Down    website 27-10-2015 2:22 Connection Timeout  0 hrs, 16 mins
Down    V3  27-10-2015 2:19 Connection Timeout  0 hrs, 19 mins
Up  website 27-10-2015 1:38 OK  0 hrs, 44 mins
Up  V3  27-10-2015 1:37 OK  0 hrs, 42 mins

Wie kan/wil mij helpen dit probleem op te lossen?
Welke logs zou ik moeten bekijken op er achter te komen wat het probleem is?
Firewall van Ubuntu zelf staat op Allow all en is ook nog eens uitgeschakeld, dus die kan t probleem niet zijn.
PHP-FPM kan het probleem niet zijn, want de niet PHP versie heeft ook problemen.
Nginx lijkt het probleem ook niet te zijn, aangezien de webmin page via IPv4 ook niet te bereiken is, en die draait via websrv.
SSH doet het op dat moment ook niet via IPv4.
IPv6 lijkt wel gewoon te blijven werken.

ps.
het gaat om:
https://www.eltomation.com/status
https://v3.eltomation.com/check.html


EDIT:
zojuist lag het er weer uit.
IPv6 blijft werken, IPv4 niet.
sudo service networking restart uitgevoerd en daarna deed het t weer.

[CAPSLOCK2000]

Heeft die server een vast adres of gebruik je DHCP?
Iedere vijf minuten een hapering die verholpen wordt door het netwerk te herstarten voelt namelijk erg als DHCP. Het klinkt alsof je firewall wordt herstart ofzo bij iedere update van DHCP.

Als dat er niks mee te maken heeft dan zou ik als algemene oplossingsstrategie met tcpdump aan de slag gaan en controleren of de pakketjes die ik verwacht ook echt aankomen en op het juiste moment en, indien dat zo is, wat er met het antwoord gebeurt.

[HellStorm666]

CAPSLOCK2000 schreef op dinsdag 27 oktober 2015 @ 18:44:
Heeft die server een vast adres of gebruik je DHCP?
Iedere vijf minuten een hapering die verholpen wordt door het netwerk te herstarten voelt namelijk erg als DHCP. Het klinkt alsof je firewall wordt herstart ofzo bij iedere update van DHCP.

Als dat er niks mee te maken heeft dan zou ik als algemene oplossingsstrategie met tcpdump aan de slag gaan en controleren of de pakketjes die ik verwacht ook echt aankomen en op het juiste moment en, indien dat zo is, wat er met het antwoord gebeurt.

Server heeft een vast IPv4 en IPv6 address.

Gegevens in /etc/network/interfaces is

code:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo eth0
iface lo inet loopback

# The primary network interface
iface eth0 inet static
        address 192.168.2.2
        netmask 255.255.255.0
        broadcast 192.168.2.255
        network 192.168.2.0
        gateway 192.168.2.1
        dns-nameservers 192.168.2.1

# This is an autoconfigured IPv6 interface
iface eth0 inet6 static
        pre-up /sbin/modprobe -q ipv6 ; /bin/true
        address 2001:981:9001:2::2
        netmask 64
        gateway 2001:981:9001:2::1

Ik zal het TCPdump verhaal eens induiken.

Ik heb de IPv6 only address ook toegevoegd aan de uptime monitor. En zie dat deze ook tegelijk met de V3 en de gewone offline gaat.

EDIT:
Al die tijd loopt er nu een tcpdump. En tot nu toe is er nog geen down-time geweest.

[Blokker_1999]

Draait deze server bare metal of draait deze op een hypervisor. Krijg ineens een klein deja-vu gevoel met een topic enige tijd terug waar iemand zijn verbinding zag wegvallen op een linux VM boven op, ik dacht, hyper-v.

[HellStorm666]

Blokker_1999 schreef op woensdag 28 oktober 2015 @ 13:15:
Draait deze server bare metal of draait deze op een hypervisor. Krijg ineens een klein deja-vu gevoel met een topic enige tijd terug waar iemand zijn verbinding zag wegvallen op een linux VM boven op, ik dacht, hyper-v.

Ubuntu server draait boven op ESXi5.5

[HellStorm666]

Nog steeds aan het stoeien met de TCP dump. Hoopte het te hebben, is blijkbaar de dump gestopt.
Nu het volgende commande gebruikt in de hoop dat het wel blijft dumpen.

code:

sudo tcpdump -vvv -i eth0 port 443 -w 443dump.log -U -C 1000

[HellStorm666]

Okay, van het weekend een tcp-dump laten draaien. 199MB aan log. Site is meerdere malen up en down geweest.

Geen idee alleen waar ik op moet letten.

CVS file met down en uptimes van uptimerobot en de TCP dump is hier te downloaden: https://files.eltomation.com/message/JyOCDcOl8X07K7s42xK1tM

Kan iemand mij a.u.b. helpen?

[Keuvie]

" You are about to view a Private Message. You need to login before viewing."

Kan bestand niet inzien.

[HellStorm666]

Keuvie schreef op maandag 02 november 2015 @ 10:03:
" You are about to view a Private Message. You need to login before viewing."

Kan bestand niet inzien.

Als t goed is kan je gewoon gratis een login maken, maar hier onder de andere oplossing.

Andere methode:
uptime csv: https://www.eltomation.co...t-all_monitors-logs_1.csv
tcp dump: https://www.eltomation.com/151030_tcpdump.log

[Keuvie]

Tijdens het downloaden van het LOG word mijn verbinding verbroken, "ERR_CONNECTION_REFUSED".

Is er misschien een firewall te scherp afgesteld?

[HellStorm666]

Keuvie schreef op maandag 02 november 2015 @ 11:22:
Tijdens het downloaden van het LOG word mijn verbinding verbroken, "ERR_CONNECTION_REFUSED".

Is er misschien een firewall te scherp afgesteld?

In de log van de firewall staat geen block naar dat bestand gemeld.

Via onedrive de link nogmaals voor de tcp: https://onedrive.live.com...RFRrfgY&ithint=file%2clog

[CAPSLOCK2000]

Ik heb de dump gewoon kunnen downloaden, geen probleem. Ik heb er even door heen gekeken maar het is te veel om allemaal te verwerken. Kun je aangeven op welk tijdstip er een storing optreedt?
Ik zie nogal wat verschillende adressen in die dump. Wat zijn de IP-adressen van je server? 192.168.2.2 en 2001:981:9001:2::2 ?

[HellStorm666]

CAPSLOCK2000 schreef op maandag 02 november 2015 @ 16:39:
Ik heb de dump gewoon kunnen downloaden, geen probleem. Ik heb er even door heen gekeken maar het is te veel om allemaal te verwerken. Kun je aangeven op welk tijdstip er een storing optreedt?
Ik zie nogal wat verschillende adressen in die dump. Wat zijn de IP-adressen van je server? 192.168.2.2 en 2001:981:9001:2::2 ?

Dat zijn inderdaad de adressen van de server.

In het csv bestand is te zien wanneer de server niet meer te vinden is (ongeveer) en wanneer wel weer.

[HellStorm666]

Misschien hebben we de oorzaak gevonden.
Het logboek van de firewall/router geeft aan dat het mac-adres van de webserver steeds veranderde.
Deze hebben we nu vastgezet (bleef daarna nog steeds veranderen) en veranderd van vmxnet3 naar e1000.

[CAPSLOCK2000]

Dat zou het prima verklaren maar dan vraag ik me wel af wat het mac-adres verandert want dat is niet normaal.

[HellStorm666]

in het log van pfSense vind ik nog steeds dat arp meld dat het mac-adres van de webserver veranderd.
Deze hadden we vastgezet ipv op auto. en als e1000 adapter ingesteld ipv vmxnet3.
Heeft niet geholpen.

Wel kan ik zien dat de arp meldingen gelijk lopen met de down meldingen van uptimerobot.
Dus het probleem is inderdaad het wisselen van mac-adres.
Wat dat veroorzaakt weet ik alleen niet.

Nu als test de adapter weer terug gezet naar vmxnet3 en een vast mac-adres gegeven. nl de gene waar ie heen blijft veranderen.

Iemand enig idee waarom een mac-adres van een virtuele ubuntu server blijft wisselen?

[_JGC_]

Als pfsense meldt dat ARP adres verandert heb je een IP-conflict in je netwerk. Er is dus nog een andere machine in je netwerk met hetzelfde IP-adres. Verklaart ook waarom ipv6 het wel gewoon blijft doen.

[HellStorm666]

_JGC_ schreef op maandag 09 november 2015 @ 10:21:
Als pfsense meldt dat ARP adres verandert heb je een IP-conflict in je netwerk. Er is dus nog een andere machine in je netwerk met hetzelfde IP-adres. Verklaart ook waarom ipv6 het wel gewoon blijft doen.

Hoe simpel het probleem soms ook kan zijn.

De AP die we voor de visitors hebben draaien kan geen ip via DHCP krijgen.
Deze stond dus blijkbaar nog op 2.2 te draaien.
En creerde dus een ip-conflikt.

Thnx voor de hulp!