Desavil

Witam, od kilku dni "obrywam" jakimś atakiem sieciowym na serwer gry Minecraft, a dokładnie po uruchomieniu serwera w netstat widzę kilkadziesiąt połączeń. Serwer gry Minecraft zaczyna nagle zużywać całą dostępną pamięć RAM serwera, aż w końcu wyłącza się - za kazdym razem kilkadziesiąt minut po jego uruchomieniu. Od razu mówię, że problem na pewno nie jest spowodowany jakimiś błędami w pluginach itp. Taka sytuacja ma również miejsce po uruchomieniu całkiem czystego serwera. Ponadto, dla testu zablokowałem cały ruch przychodzący (iptables -I INPUT -j DROP) i dodałem kilka zaufanych adresów IP i wszystko działało dobrze, wystarczy tylko zezwolić wszystkim na połączenia, a problem będzie się powtarzał z zajęciem całej dostępnej pamięci RAM. Próbowałem w różny sposób limitować już ruch za pomocą iptables (np. synflood) i niestety nic z tego. W netstat można zauważyć, że większość połączeń jest z zagranicy, a ich nazwy hostów to np. tor, exitnode, torproxy itp. Na wykresach nie widzę żadnych "szpilek", zwiększonego ruchu sieciowego. Będę wdzięczny, jeżeli ktoś mógłby rzucić okiem na poniższe logi. Przesyłam również plik binarny z logami tcpdump (do odczytania w np. Wireshark), w momencie występowania ataku. Logi tcpdump: https://www.dropbox.com/s/8gjvq21xfphkuh5/tcpdump.bin?dl=0 Wynik polecenia netstat - serwer działa za NATem (lokalizacja OVH) jego adres IP oraz port: 192.168.0.98:20186. Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp6 0 0 :::20196 :::* LISTEN 1370/java tcp6 0 0 :::20186 :::* LISTEN 1370/java tcp6 79816 0 192.168.0.98:20186 194.150.168.95:58779 ESTABLISHED 1370/java tcp6 77440 0 192.168.0.98:20186 94.242.246.23:50608 ESTABLISHED - tcp6 29 0 192.168.0.98:20186 31.175.85.223:52497 CLOSE_WAIT 1370/java tcp6 0 0 192.168.0.98:43131 190.93.246.102:443 TIME_WAIT - tcp6 78150 0 192.168.0.98:20186 5.196.28.199:45739 ESTABLISHED - tcp6 65662 0 192.168.0.98:20186 178.238.223.67:62375 ESTABLISHED - tcp6 77788 0 192.168.0.98:20186 77.95.229.16:59171 ESTABLISHED 1370/java tcp6 0 0 192.168.0.98:34086 107.170.1.65:80 TIME_WAIT - tcp6 67076 0 192.168.0.98:20186 77.247.181.162:46842 ESTABLISHED - tcp6 21 0 192.168.0.98:20186 83.27.18.60:50098 CLOSE_WAIT 1370/java tcp6 78154 0 192.168.0.98:20186 95.130.15.97:59953 ESTABLISHED - tcp6 77602 0 192.168.0.98:20186 18.239.0.140:36777 ESTABLISHED 1370/java tcp6 77822 0 192.168.0.98:20186 176.126.252.11:36359 ESTABLISHED 1370/java tcp6 75682 0 192.168.0.98:20186 94.242.246.23:35013 ESTABLISHED 1370/java tcp6 78156 0 192.168.0.98:20186 94.242.246.24:52230 ESTABLISHED - tcp6 79184 0 192.168.0.98:20186 62.210.74.186:42649 ESTABLISHED - tcp6 77940 0 192.168.0.98:20186 77.95.229.16:60883 ESTABLISHED - tcp6 65420 0 192.168.0.98:20186 37.187.129.166:48503 ESTABLISHED - tcp6 76900 0 192.168.0.98:20186 64.113.32.29:58028 ESTABLISHED 1370/java tcp6 71394 0 192.168.0.98:20186 94.242.246.24:46867 ESTABLISHED 1370/java tcp6 78114 0 192.168.0.98:20186 195.154.251.25:33633 ESTABLISHED - tcp6 80420 0 192.168.0.98:20186 5.196.28.199:42352 ESTABLISHED - tcp6 0 0 192.168.0.98:2535 190.93.245.100:80 TIME_WAIT - tcp6 78370 0 192.168.0.98:20186 77.247.181.162:38742 ESTABLISHED - tcp6 78208 0 192.168.0.98:20186 176.126.252.12:51483 ESTABLISHED - tcp6 65948 0 192.168.0.98:20186 176.126.252.11:58058 ESTABLISHED 1370/java tcp6 66460 0 192.168.0.98:20186 94.242.246.24:56327 ESTABLISHED - tcp6 21 0 192.168.0.98:20186 83.27.18.60:50132 CLOSE_WAIT - tcp6 78370 0 192.168.0.98:20186 77.247.181.162:46975 ESTABLISHED - tcp6 76004 0 192.168.0.98:20186 82.211.223.3:38178 ESTABLISHED 1370/java tcp6 0 0 192.168.0.98:43106 190.93.246.102:443 TIME_WAIT - tcp6 20 0 192.168.0.98:20186 83.8.30.212:59570 CLOSE_WAIT 1370/java tcp6 66428 0 192.168.0.98:20186 64.113.32.29:58102 ESTABLISHED - tcp6 77512 0 192.168.0.98:20186 128.52.128.105:49029 ESTABLISHED - tcp6 66598 0 192.168.0.98:20186 96.47.226.22:60178 ESTABLISHED - tcp6 20 0 192.168.0.98:20186 178.239.10.217:60260 ESTABLISHED - tcp6 21 0 192.168.0.98:20186 83.27.18.60:50133 CLOSE_WAIT - tcp6 76670 0 192.168.0.98:20186 5.196.28.199:39670 ESTABLISHED 1370/java tcp6 77510 0 192.168.0.98:20186 95.130.15.97:47819 ESTABLISHED - tcp6 77810 0 192.168.0.98:20186 176.126.252.11:58449 ESTABLISHED - tcp6 78210 0 192.168.0.98:20186 96.47.226.22:43974 ESTABLISHED - tcp6 79398 0 192.168.0.98:20186 5.196.28.199:39588 ESTABLISHED 1370/java tcp6 77512 0 192.168.0.98:20186 96.44.189.101:56533 ESTABLISHED - tcp6 75758 0 192.168.0.98:20186 176.126.252.12:44915 ESTABLISHED 1370/java tcp6 78548 0 192.168.0.98:20186 37.187.129.166:52988 ESTABLISHED 1370/java tcp6 58 0 192.168.0.98:20186 78.68.10.38:50656 ESTABLISHED - tcp6 0 0 192.168.0.98:20186 62.210.74.186:51981 ESTABLISHED - tcp6 78252 0 192.168.0.98:20186 95.130.15.97:59979 ESTABLISHED - tcp6 79692 0 192.168.0.98:20186 5.196.28.199:44892 ESTABLISHED - tcp6 67376 0 192.168.0.98:20186 64.113.32.29:46567 ESTABLISHED - tcp6 79384 0 192.168.0.98:20186 77.247.181.162:58493 ESTABLISHED 1370/java tcp6 78382 0 192.168.0.98:20186 176.126.252.11:33966 ESTABLISHED - tcp6 77220 0 192.168.0.98:20186 95.130.15.97:42660 ESTABLISHED 1370/java tcp6 67296 0 192.168.0.98:20186 77.247.181.162:38747 ESTABLISHED 1370/java tcp6 77052 0 192.168.0.98:20186 82.211.223.3:54678 ESTABLISHED - tcp6 66710 0 192.168.0.98:20186 91.121.169.33:46798 ESTABLISHED - tcp6 81868 0 192.168.0.98:20186 178.217.187.39:57465 ESTABLISHED 1370/java tcp6 77050 0 192.168.0.98:20186 195.154.251.25:52634 ESTABLISHED - tcp6 76976 0 192.168.0.98:20186 128.52.128.105:41392 ESTABLISHED 1370/java tcp6 16384 0 192.168.0.98:20186 94.242.246.23:57436 ESTABLISHED - tcp6 78648 0 192.168.0.98:20186 5.196.28.199:42743 ESTABLISHED - tcp6 78534 0 192.168.0.98:20186 178.238.223.67:63838 ESTABLISHED - tcp6 66390 0 192.168.0.98:20186 91.121.169.33:50483 ESTABLISHED - tcp6 78050 0 192.168.0.98:20186 82.211.223.3:54608 ESTABLISHED - tcp6 78356 0 192.168.0.98:20186 194.150.168.95:45666 ESTABLISHED - tcp6 77734 0 192.168.0.98:20186 5.196.28.199:39712 ESTABLISHED 1370/java tcp6 78798 0 192.168.0.98:20186 128.52.128.105:45040 ESTABLISHED - tcp6 76788 0 192.168.0.98:20186 96.44.189.101:36869 ESTABLISHED 1370/java tcp6 68788 0 192.168.0.98:20186 5.196.28.199:39594 ESTABLISHED 1370/java tcp6 79474 0 192.168.0.98:20186 5.196.28.199:44898 ESTABLISHED - tcp6 77118 0 192.168.0.98:20186 195.154.251.25:45166 ESTABLISHED - tcp6 68558 0 192.168.0.98:20186 178.238.223.67:63146 ESTABLISHED 1370/java tcp6 78560 0 192.168.0.98:20186 176.126.252.12:33436 ESTABLISHED - tcp6 77958 0 192.168.0.98:20186 5.196.28.199:42343 ESTABLISHED 1370/java tcp6 0 0 192.168.0.98:2516 190.93.245.100:80 TIME_WAIT - tcp6 77144 0 192.168.0.98:20186 5.196.28.199:42346 ESTABLISHED 1370/java tcp6 1 0 192.168.0.98:20186 5.196.178.73:41957 CLOSE_WAIT 1370/java tcp6 0 0 192.168.0.98:29246 107.170.7.99:80 TIME_WAIT - tcp6 79146 0 192.168.0.98:20186 178.217.187.39:56298 ESTABLISHED - tcp6 0 0 192.168.0.98:4687 54.173.214.28:80 TIME_WAIT - tcp6 72144 0 192.168.0.98:20186 96.44.189.100:52293 ESTABLISHED 1370/java tcp6 78176 0 192.168.0.98:20186 176.126.252.11:48591 ESTABLISHED - tcp6 77550 0 192.168.0.98:20186 195.154.251.25:51234 ESTABLISHED 1370/java tcp6 78210 0 192.168.0.98:20186 77.247.181.162:47017 ESTABLISHED - tcp6 0 0 192.168.0.98:2515 190.93.245.100:80 TIME_WAIT - tcp6 66426 0 192.168.0.98:20186 176.126.252.11:54586 ESTABLISHED - tcp6 81296 0 192.168.0.98:20186 79.134.234.200:39367 ESTABLISHED 1370/java tcp6 67538 0 192.168.0.98:20186 77.247.181.162:58507 ESTABLISHED 1370/java tcp6 21 0 192.168.0.98:20186 78.68.10.38:57238 CLOSE_WAIT 1370/java tcp6 78142 0 192.168.0.98:20186 77.247.181.162:38736 ESTABLISHED 1370/java tcp6 78196 0 192.168.0.98:20186 82.211.223.3:46244 ESTABLISHED - tcp6 21 0 192.168.0.98:20186 83.27.18.60:50097 CLOSE_WAIT 1370/java tcp6 0 0 192.168.0.98:29253 107.170.7.99:80 TIME_WAIT - tcp6 77520 0 192.168.0.98:20186 96.44.189.101:45848 ESTABLISHED - tcp6 78466 0 192.168.0.98:20186 91.121.169.33:43178 ESTABLISHED 1370/java tcp6 77884 0 192.168.0.98:20186 37.187.129.166:37370 ESTABLISHED - tcp6 80108 0 192.168.0.98:20186 194.150.168.95:37660 ESTABLISHED - tcp6 77990 0 192.168.0.98:20186 77.247.181.162:58499 ESTABLISHED 1370/java tcp6 79632 0 192.168.0.98:20186 37.187.129.166:37266 ESTABLISHED 1370/java tcp6 82474 0 192.168.0.98:20186 79.134.234.200:40724 ESTABLISHED 1370/java tcp6 78304 0 192.168.0.98:20186 82.211.223.3:46253 ESTABLISHED - tcp6 80142 0 192.168.0.98:20186 95.130.15.97:47869 ESTABLISHED - tcp6 76552 0 192.168.0.98:20186 79.134.234.200:42025 ESTABLISHED - tcp6 76782 0 192.168.0.98:20186 5.196.28.199:44891 ESTABLISHED - tcp6 80954 0 192.168.0.98:20186 178.217.187.39:35466 ESTABLISHED 1370/java tcp6 77598 0 192.168.0.98:20186 37.187.129.166:48620 ESTABLISHED - Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 2 [ ] STREAM CONNECTED 1270227278 1370/java unix 2 [ ] STREAM CONNECTED 1270227268 1370/java

Fakt, z tym TORem sprawdza się. Musiałem ustawić jeszcze częstszą aktualizację list exit nodów, niż raz dziennie.

Przez ostatnie kilka dni próbowałem znaleźć w internetach coś na wzór tego jakim atakiem obrywam, w skrócie atak który powoduje zużycie całej dostępnej ilości pamięci RAM przez serwer w szybkim tempie, aż proces zostaje zabity (testowałem na serwerach 16GB RAM, 32GB RAM, 64GB RAM), więc metoda ataku jest taka sama. Nigdzie nie znalazłem informacji, aby ktoś miał podobne problemy. Tak też myślałem na początku, ale to się nie sprawdzi niestety (chyba, że się mylę). Dla przykładu, dla którego przeprowadziłem test -zablokowałem cały ruch przychodzący i odblokowałem tylko jedno losowe IP z poprzedniego ataku, widać że jeden host może spowodować takie zachowanie serwera. A w logach z tcpdumpa (https://www.dropbox.com/s/niotztxrzlkzauk/tcpdump2.bin?dl=0) widać, że SYNów było tylko 6 i to w dużych odstępach. Najwięcej było pakietów ACK i PSH, ACK (tych nieco mniej), bo aż 2948 z adresu IP źródłowego hosta atakującego - wszystko od momentu uruchomienia serwera (rozpoczęcie ataku), aż do zakończenia ataku (wyłączenie się serwera z powodu out of memory procesu). Oczywiście nie chodzi mi tutaj też o jakieś gotowe rozwiązania, tylko o jakieś nakierowanie mnie na co mam zwrócić uwagę, aby zablokować ten atak.

Chyba będę musiał, bo przez iptables tego nie zablokuje na to wygląda.

Po zablokowaniu ruchu z TORa przez ok. 1-2 dni był spokój. Teraz znów to samo i leci z wszystkich lokalizacji, uk, ovh, leaseweb i inne, więc blokowanie po geolokalizacji tutaj się nie sprawdzi, gdyż musiałbym odciąć praktycznie cały świat, a zostawić tylko Polskę co nie wchodzi w grę. Jakby to były adresy z samych Chin, Rosji to jeszcze nie byłoby problemu. Po uruchomieniu serwera widzę, kilkadziesiąt połączeń z różnych adresów IP. Postanowiłem zablokować cały ruch przychodzący i zaakceptować dowolny losowy adres IP z tej listy, włączyłem logowanie pakietów dla tego adresu IP i serwer też się wyłączył, czyli najprawdopodobniej wysyłane jest to samo przez wszystkie hosty, a tak naprawdę wystarczy tylko atak z jednego serwera. Od początku do końca (do momentu out of memory, kiedy aplikacja już wyłączyła się w wyniku ataku) posiadam logi binarne tcpdump - https://www.dropbox.com/s/niotztxrzlkzauk/tcpdump2.bin?dl=0 Zastanawiam się co jeszcze mogę tutaj zrobić, aby zablokować skutecznie ten atak. Z tego co widać serwer atakujący wysyła dużą ilość pakietów ACK, ale widać też że SYN Flood to nie jest, gdyż nie widać dużo pakietów tego typu.

Witam, jakiś czas temu skonfigurowałem sobie OpenVPN serwer i klient. Wszystko działało idealnie, aż do czasu kiedy zrobiłem restart maszyny, na której zainstalowany jest OpenVPN serwer. Niestety od tego czasu nie umiem w żaden sposób przywrócić komunikacji. Jeżeli chodzi o samą konfigurację OpenVPN jestem pewny, że tutaj jest wszystko dobrze, a problem występuje na etapie samego firewalla na serwerze. OpenVPN serwer nie ma umożliwiać klientowi komunikacji po jego adresie IP, tylko służy do nawiązania samego, bezpiecznego połączenia z serwerem. Obecna konfiguracja: /etc/sysctl.conf net.ipv4.conf.all.forwarding = 1 net.ipv4.ip_forward = 1 W firewallu mam: iptables -P FORWARD ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE iptables -A INPUT -p tcp --dport 1194 -j ACCEPT Przypuszczam, że przedtem metodą prób i błędów musiałem coś dodać do iptables i po restarcie serwera się to usunęło (zapomniałem uaktualnić plik z firewallem). Co tutaj jest ew. źle, co zmienić w iptables? ifconfig z serwera: tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.1.0.1 P-t-P:10.1.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Jeszcze logi z klienta: Thu Jan 15 19:56:33 2015 OpenVPN 2.3.6 x86_64-w64-mingw32 [SSL (OpenSSL)] [LZO] [PKCS11] [IPv6] built on Dec 1 2014 Thu Jan 15 19:56:33 2015 library versions: OpenSSL 1.0.1j 15 Oct 2014, LZO 2.08 Thu Jan 15 19:56:33 2015 MANAGEMENT: TCP Socket listening on [AF_INET]127.0.0.1:25340 Thu Jan 15 19:56:33 2015 Need hold release from management interface, waiting... Thu Jan 15 19:56:34 2015 MANAGEMENT: Client connected from [AF_INET]127.0.0.1:25340 Thu Jan 15 19:56:34 2015 MANAGEMENT: CMD 'state on' Thu Jan 15 19:56:34 2015 MANAGEMENT: CMD 'log all on' Thu Jan 15 19:56:34 2015 MANAGEMENT: CMD 'hold off' Thu Jan 15 19:56:34 2015 MANAGEMENT: CMD 'hold release' Thu Jan 15 19:56:34 2015 Control Channel Authentication: using 'ta.key' as a OpenVPN static key file Thu Jan 15 19:56:34 2015 Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Jan 15 19:56:34 2015 Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication Thu Jan 15 19:56:34 2015 Socket Buffers: R=[8192->8192] S=[8192->8192] Thu Jan 15 19:56:34 2015 MANAGEMENT: >STATE:1421348194,RESOLVE,,, Thu Jan 15 19:56:34 2015 Attempting to establish TCP connection with [AF_INET]x.x.x.x:1194 [nonblock] Thu Jan 15 19:56:34 2015 MANAGEMENT: >STATE:1421348194,TCP_CONNECT,,, Thu Jan 15 19:56:44 2015 TCP: connect to [AF_INET]x.x.x.x:1194 failed, will try again in 5 seconds: System próbowa³ sprzêgn¹æ dysk z katalogiem na dysku sprzêgniêtym. Thu Jan 15 19:56:49 2015 MANAGEMENT: >STATE:1421348209,RESOLVE,,, Thu Jan 15 19:56:49 2015 MANAGEMENT: >STATE:1421348209,TCP_CONNECT,,, Thu Jan 15 19:56:59 2015 TCP: connect to [AF_INET]x.x.x.x:1194 failed, will try again in 5 seconds: System próbowa³ sprzêgn¹æ dysk z katalogiem na dysku sprzêgniêtym. Thu Jan 15 19:57:04 2015 MANAGEMENT: >STATE:1421348224,RESOLVE,,, Thu Jan 15 19:57:04 2015 MANAGEMENT: >STATE:1421348224,TCP_CONNECT,,, Thu Jan 15 19:57:14 2015 TCP: connect to [AF_INET]x.x.x.x:1194 failed, will try again in 5 seconds: System próbowa³ sprzêgn¹æ dysk z katalogiem na dysku sprzêgniêtym. Thu Jan 15 19:57:19 2015 MANAGEMENT: >STATE:1421348239,RESOLVE,,, Thu Jan 15 19:57:19 2015 MANAGEMENT: >STATE:1421348239,TCP_CONNECT,,,

Już znalazłem źródło problemu. Usługodawca po ostatnich mocnych atakach na mój serwer musiał zablokować port, na którym mam ustawiony OpenVPN (chyba zapomniałem przekazać do wyjątków, hmm).

Sprawdzę. Generalnie chodzi mi o to, aby była komunikacja również pomiędzy klientami OpenVPN - do tego też nic nie potrzebuję (przedtem oczywiście działało)? @ Edit W logach po stronie serwera pusto, żadnych prób połączenia, błędów itp. Tak jakby nie dochodziło w ogóle do niego. @ Edit 2 Po całkowitym zrestartowaniu firewalla i wszystko na ACCEPT, to samo.

Z tego co widziałem, ilość połączeń per ip to ok. 3 (z tych atakujących). Tak jak pisałem w pierwszym poście - próbowałem już na różne sposoby to limitować przez iptables i mi nie wyszło. @Edit Dodaję, jak zablokować TORa, może się komuś przyda w przyszłości. Instalujemy pakiety (użyłem ipset, bo jest do tego najlepszy): apt-get install ipset curl Dodajemy (do np. /etc/rc.local) poniższe linie, aby przy starcie/restarcie blokowanie uruchomiło się: ipset create torblock iphash curl -s https://check.torproject.org/exit-addresses | grep -E -o "(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)" | sort -n | uniq | xargs -n 1 ipset add torblock iptables -I INPUT -m set --match-set torblock src -j DROP Dodajemy do crona (/etc/crontab) poniższą linię, aby codziennie o godz. 2:00 aktualizowało nam listę adresów: 0 2 * * * root ipset flush torblock && curl -s https://check.torproject.org/exit-addresses | grep -E -o "(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)" | sort -n | uniq | xargs -n 1 ipset add torblock Oczywiście można byłoby to zrobić bez wyrażeń regularnych (komendy byłyby krótsze), ale lepiej użyć tego jako dodatkowego zabezpieczenia, jakby zamiast adresu IP, podali np. jakieś "rm" i wykonałoby nam się to przez "xargs". Jeżeli ktoś ma jeszcze jakieś warte uwagi listy z adresami IP, które warto zablokować, prosiłbym o umieszczenie ich tutaj.

To oczywiście może być dobrym rozwiązaniem, ale myślę że na dłuższą metę niestety nie. :/

Oczywiście, że nie. Ale zawsze warto sprawdzić wszystko. Kierowałem się tym:

Dokładnie, problem wyglądał bardzo podobnie. Później to testowałem i faktycznie problemem były DNSy ustawione w resolv.conf, chociaż sam się dziwiłem że to może powodować ten problem.

Ojj pracy to u nich było, było i było tak, że w końcu po kilku miesiącach tych ich "prac" i obiecywanek musiałem się niestety wynieść. Mógłbyś podrzucić jakieś screeny na PW, jestem ciekaw jak to w rzeczywistości wygląda?

Jakie masz ustawione serwery DNS na VPSie? Może to dziwne, ale miałem kilka miesięcy podobny problem i trochę się naszukałem rozwiązania, a problemem ukazało się ustawienie DNSów na serwerze innych niż domyślne - przy stawianiu nowego serwera zmieniałem tą konfigurację od razu.

Przerabiałem też ten temat. Jak z polski to jedynie sprintdatacenter. Jak się dobrze dogadasz to możesz uzyskać transfer bez limitu i przepustowość 500Mbps w dobrej cenie. Rurki 1Gbps już "trochę" droższe. Średnie zużycie łącza miałem co najmniej 100Mbps przez cały dzień, a w godzinach szczytu ok. 250-300Mbps. I trwało to stale przez kilka dobrych miesięcy i nie było żadnego problemu. Swoją drogą, ktoś wie jak teraz wygląda u nich stabilność łącza i jak radzą sobie z atakami DDoS? Czy nadal jak jest jakiś atak na jednego klienta, to pada im całe łącze tj. na pozostałych serwerach? PS. Bardzo ciekawie wygląda również oferta nowej marki - serwery.pl i warto się ku temu zastanowić, ale niestety jak na razie nie wiadomo jakie są te faktyczne w miarę "gwarantowane" parametry łącza i jak jest z limitami transferu, bo w jednych miejscach piszą, że bez limitu, a znów w innych że po przekroczeniu X TB obcinają rurkę. Niby w opisie jest też "Przepustowość łącza 1 Gbit. Oferowana przepustowość łącza na poziomie aż 1 Gbit gwarantuje najwyższą wydajność."

Mogę polecić program Microsoft SharePoint Designer 2007 (który o dziwo jest DARMOWY!), jest następcą programu Microsoft FrontPage - http://www.microsoft.com/pl-pl/download/details.aspx?id=21581 Nie polecam ściągać wersji 2010, gdyż tam już trzeba to z czymś łączyć, co jest płatne.

Może już skończyć ten offtopic? Nie warto się kłócić. Odnośnie tematu, zainstalowałem gruba na drugim dysku, chirurdzy wymienili dysk, rana się zagoiła - pacjent przeżył.

Witam, z tego co już się dowiedziałem DRBD działa głównie w LANie, jeżeli chce się udostępniać zasoby przez sieć Internet trzeba już posiadać licencję na DRBD Proxy (nigdzie niestety nie znalazłem ceny). Czy może ktoś polecić jakąś w pełni darmową alternatywę dla samego DRBD Proxy (o ile takie rozwiązanie istnieje) lub też dla całego DRBD? Pozdrawiam!

Pisałem do nich maila i wspomniałem o OpenVPN i napisali tylko "Ok". DRBD-Proxy nie wchodzi w grę - 590,00€ per node per year. Pytali też o dystans, więc podałem: 1300 km / ping pomiędzy lokalizacjami: ~30 ms I stwierdzili, że za duża odległość. Stwierdzili też, że klaster działa bezpiecznie w odległości do 100 km.

Jeszcze się zastanawiam nad uruchomieniem tego przez tunel OpenVPN. Takie zastosowanie miałoby dwie zalety: - Transmisja jest szyfrowana (domyślnie DRBD nie oferuje szyfrowania, więc i tak byłoby to niezbędne) - Nie muszę kupować licencji na DRBD Proxy, bo całość uruchomiona jest w sieci VLAN. Czy tak zadziałałoby to?

Witam, chciałbym poradzić się w jaki sposób najlepiej mógłbym zrobić High Availability dla bazy/serwera MySQL. Przykładowo - mam postawionego proftpd'a z MySQL. W lokalizacji A znajduje się serwer MySQL i baza, a z bazą łączą się klienci z lokalizacji A,B,C,D,[...]. Jeżeli padnie łącze pomiędzy serwerami w lokalizacjach np. A i D wtedy z FTP nie połączą się klienci z serwera D. Mam pomysł na dwa rozwiązania w takim wypadku: 1. Użycie proxy - jeżeli jest jakiś problem w komunikacji, system przełącza ruch przez inny serwer, aby dostać się do serwera z bazą danych, przez inny serwer. 2. Replikacja: master-master. Całkiem sensownie wygląda drugie rozwiązanie, gdyż ma wiele pozytywów jakie można dostrzec, np. jeżeli fizycznie padnie serwer z bazą danych, lub też po stronie aplikacji coś padnie to wtedy korzysta z drugiego niezależnego serwera master z innej lokalizacji. Co w przypadku pierwszego rozwiązania w takiej sytuacji wszystko pada. Ale zastanawia mnie jedna kwestia przy tego typu rozwiązaniu. Postawię sobie dwa mastery w lokalizacji A oraz B, wszystko ładnie. Ale pada połączenie pomiędzy A oraz B i co w takiej sytuacji? Dane już nie będą spójne. Bo klienci łączący się z bazą danych będą lądować na losowy serwer (chyba tak to działa) - dajmy przykładowo na FTP łączy się użytkownik: kot przesyła pliki w bazie na serwerze A robią się update z sumą wgranych plików. Rozłącza się, za kilka minut znów łączy się na FTP, tym razem trafia, że "wskoczył" serwer bazy w lokalizacji B, wgrywa pliki, lecą update do bazy. Łącze pomiędzy A i B wstaje, i co wtedy? Wartości są zupełnie różne w obydwóch lokalizacjach. A co najlepsze, mamy jakiś web-panel do zarządzania tymi użytkownikami FTP w lokalizacji D (której łącze ma dostęp do obydwóch serwerów MySQL, ale pamiętajmy że łącze pomiędzy samymi serwerami master nadal leży) robi się select i co chwile wskakują inne wartości? Macie jakieś doświadczenie z HA w MySQL, jak mógłbym to rozwiązać? FTP to oczywiście przykład, który nasunął mi się jako pierwszy, aby na tym to opisać.

W putty po lewej stronie wybierasz: Connection > SSH > Auth a następnie przy "Private key file for authentication" klikasz "Browse..." i wybierasz plik z kluczem.

Teraz działa, ale padło na kilka minut.

Tylko OVH - 49,99 zł brutto. Po co przepłacać?

Witam, mam w soyoustart serwer z MegaRAID Cache + bateria. W jaki sposób mogę sprawdzić, czy macierz działa prawidłowo? Wykonywałem komendy typu: MegaCli -LDInfo -Lall -Aall Ale zwraca jedynie: Exit Code: 0x00