Ubuntu server odmítá spojení z vnější sítě

[ragimiri]

Dobrý den, moc prosím o pomoc, jsem už zoufalý. Mám Ubuntu server 12.04 LTS. Server je umístěný za NAT, který přesměrovává port 443 na tento server. Server v náhodných okamžicích začne odmítat spojení zvenku, tzn. pokud si někdo chce na Internetu otevřít webovou stránku ze serveru, dojde k timeoutu. Divné ale je, že já si webovou stránku z vnitřní sítě můžu otevřít i v době, kdy to zvenku nejde. Původně jsem podezíral náš NAT, jenže teď jsem tam dal jiný typ a dělá to to samé. Pak jsem podezíral i switche na cestě, jenže na ty je připojený i jiný server na jiném portu, a ten funguje i v době, kdy Ubuntu ne. Takže jediný viník je logicky Ubuntu server. Pokud na něm v době výpadku spustím "sudo ifdown eth0 && sudo ifup eth0'", tak se síť zase na nějakou dobu rozběhne. Nechápu ale, proč to dělá jen a pouze u spojení zvenku.

[Petr Merlin Vaněček]

Kolik je v takové chvíli navázáno spojení? Nezahazuje to apache v důsledku limitu?

[ragimiri]

Počty spojení jsou v řádu jednotek, navíc to nevysvětluje, proč spojení z vnitřní sítě jdou, zatímco z venkovní sítě ne.

[ragimiri]

Schválně jsem dokonce zpřístupnil i jiné služby (SSH, Squid), abych vyloučil, že je chyba v Apachi.

[Petr Merlin Vaněček]

a?

[ragimiri]

To bylo už předtím, server neodpovídá na vnější podněty na žádném portu. Na vnitřní síti vesele komunikuje dál. Opravdu jsem nejvíce podezíral NAT (když to nejde jen zvenku, je první na řadě), jenže problémy byly už před výměnou, takže to bych vyloučil. A divné je, že se to spraví po restartu síťového rozhraní. Tak jestli nevyšla nějaká aktualizace driveru síťové karty nebo tak něco? Už fakt nevím, na co se zaměřit.

[Petr Merlin Vaněček]

Jsou tam nějaká pravidla iptables?

[ragimiri]

Ano, jsou:

Kód: [Vybrat]

*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -s 10.248.0.0/16 -j ACCEPT
-A INPUT -p icmp --icmp-type 8 -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
COMMIT

Ale iptables jsem podezíral také, takže jsem je dočasně vypnul.

Jen pro ilustraci jsem přiložil výpis toho, jak se chování serveru jeví zvenku.

[příloha smazaná administrátorem]

[ragimiri]

Asi dám do crona, aby se síť restartovala každou hodinu.

[Petr Merlin Vaněček]

V logu není nic? Co chyby sítě?

[ntz_reloaded]

-A INPUT -s 10.248.0.0/16 -j ACCEPT

^^ muzes se prosim kouknout pomoci tcpdumpu, co presne dela router s tema paketama ? podle toho co pises bych cekal, ze je neSNATuje

[ragimiri]

V logu není nic? Co chyby sítě?

Absolutně nic. Právě to mě mate.

-A INPUT -s 10.248.0.0/16 -j ACCEPT

^^ muzes se prosim kouknout pomoci tcpdumpu, co presne dela router s tema paketama ? podle toho co pises bych cekal, ze je neSNATuje

Zkusit to můžu, ale pokud by byla chyba zde, pak by to nefungoval vůbec. A ono to nefunguje jen někdy a různě dlouhou dobu a jen zvenku.

[ragimiri]

Tak když je výpadek, server nepřijímá žádný požadavek zvenku, jen zevnitř. Takže pakety mizí mezi NAT a serverem. NAT se tváří, že vše předává, server se tváří, že žádné požadavky nedostává. Tohle fakt není normální.

[ragimiri]

Dal jsem server i do DMZ, vypnul firewall, úplně ho vystavil a prd. Žádná komunikace. Prokletý Linux, převedu služby na Windows a bude to.

[Petr Merlin Vaněček]

Dal jsem server i do DMZ, vypnul firewall, úplně ho vystavil a prd. Žádná komunikace. Prokletý Linux, převedu služby na Windows a bude to.

Převeď. Nikdo zde není zvědavý na podobné vydírání.

[ragimiri]

Narazil jsem ještě na něco. Když se na NATu podívám do ARP tabulky, tak adresa serveru tam není. Pokud ze serveru pingnu ven, tak se adresa v ARP tabulce objeví a server je nějakou dobu dostupný. Jenže potom zase zmizne a jsem tam, kde jsem byl. Jenže ARP tabulka by se přece měla aktualizovat automaticky, nebo ne?

[ragimiri]

Dal jsem server i do DMZ, vypnul firewall, úplně ho vystavil a prd. Žádná komunikace. Prokletý Linux, převedu služby na Windows a bude to.

Převeď. Nikdo zde není zvědavý na podobné vydírání.

To není vydírání, to je výraz zoufalství. Pokud mi dva servery umístěné vedle sebe na tom samém switchi fungují stylem, že Windows 2012 jede a Ubuntu 12.04 ne, pak nemám jinou možnost, než zvolit to, co funguje. Byť mě to netěší, raději mám Apache na Linuxu než IIS na Windows.

[Petr Merlin Vaněček]

Dal jsem server i do DMZ, vypnul firewall, úplně ho vystavil a prd. Žádná komunikace. Prokletý Linux, převedu služby na Windows a bude to.

Převeď. Nikdo zde není zvědavý na podobné vydírání.

To není vydírání, to je výraz zoufalství. Pokud mi dva servery umístěné vedle sebe na tom samém switchi fungují stylem, že Windows 2012 jede a Ubuntu 12.04 ne, pak nemám jinou možnost, než zvolit to, co funguje. Byť mě to netěší, raději mám Apache na Linuxu než IIS na Windows.

Jenže podat to takto znamená jen si lidi proti sobě poštvat.

Narazil jsem ještě na něco. Když se na NATu podívám do ARP tabulky, tak adresa serveru tam není. Pokud ze serveru pingnu ven, tak se adresa v ARP tabulce objeví a server je nějakou dobu dostupný. Jenže potom zase zmizne a jsem tam, kde jsem byl. Jenže ARP tabulka by se přece měla aktualizovat automaticky, nebo ne?

Zkus prohodit kabely na switchi, dost možná má chudák nemocnou cache.

[ntz_reloaded]

co kdybys misto fnukani a vyhrozovani treba zkusil ten tcpdump ?

[ragimiri]

co kdybys misto fnukani a vyhrozovani treba zkusil ten tcpdump ?

Psal jsem, že jsem ho zkusil. Příchozí pakety zvenku žádné. Nefiltrovaný výstup dává informací až moc, přiznám se, že se v nich nevyznám.

[ragimiri]

Zkus prohodit kabely na switchi, dost možná má chudák nemocnou cache.

Jdu na to. Zkusím pak server ještě připojit přímo k NATu, abych vyloučil cokoliv se switchem. A pokud nepomůže, tak ho zkusím zapojit přímo na internetový router. To by v tom byl čert, aby něco nepomohlo.

[Petr Merlin Vaněček]

Jak to dopadlo?

[ragimiri]

Bohužel bez úspěchu, chová se to pořád stejně. Uvidíme v dubnu, to dostanu nový server a buď na něm půjde Ubuntu 14.04 LTS, nebo Windows 2012. Doufám, že to bude Ubuntu, IIS já nerad.