ubuntu 10.04 server błędy przy restarcie iptables

[marcintpi]

Witam
Iptables konfigurowałem według bardzo dobrego poradnika na tym forum viewtopic.php?p=613705 i wszystko działało by bardzo dobrze gdyby nie taki błąd przy próbie zrestartowania iptables

Kod: Zaznacz cały

WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
FATAL: Module ip_tables not found.
iptables v1.4.4: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
WARNING: Deprecated config file /etc/modprobe.conf, all config files belong into /etc/modprobe.d/.
FATAL: Module ip_tables not found.
iptables v1.4.4: can't initialize iptables table `nat': Table does not exist (do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
iptables: No chain/target/match by that name.
iptables: No chain/target/match by that name.

Oczywiście nie jest to wina konfiguracji bo poradnik jest sprawdzony i działa bardzo dobrze z tego co wypisało w konsoli to wydaje się, że trzeba zaktualizować kernel no właśnie ale jak by nie rozwalić systemu :/?
Nie czuję się mocny jeżeli chodzi o ubuntu dlatego proszę Was o pomoc w tej sprawie.

Pozdrawiam i nie ukrywam, że sprawa pilna :/

[norvoles]

wszystko działało by bardzo dobrze gdyby nie taki błąd przy próbie zrestartowania iptables

W jakim celu restartujesz iptables? Skrypt ustawiający reguły dla iptables ma efekt natychmiastowy. Czy o czymś nie wiem?

[marcintpi]

OK powiedzmy, że masz rację jednak mimo wszystko nie powinien pojawiać się w/w komunikat o błędach

Oczywiście mogę się mylić, skoro tak jest bardzo proszę o poprawienie mnie.

[norvoles]

OK powiedzmy, że masz rację jednak mimo wszystko nie powinien pojawiać się w/w komunikat o błędach

Może to zależy od tego jak iptables próbujesz przeładować? Nie napisałeś jaka komenda wyrzuca taki komunikat, więc nie ma m jak zweryfikować.
Jeśli masz jakieś wątpliwości co do tego, czy i jakie reguły zostały ustawione to użyj:

Kod: Zaznacz cały

iptables -L

[marcintpi]

Podtrzymam jeszcze temat bo mam taki mały problem tz. iptables mam ustawiony tak:

Kod: Zaznacz cały

Chain INPUT (policy DROP)
target     prot opt source               destination         
fail2ban-proftpd  tcp  --  anywhere             anywhere            multiport dports ftp,ftp-data,ftps,ftps-data 
fail2ban-ssh  tcp  --  anywhere             anywhere            multiport dports ssh 
ACCEPT     all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            icmp echo-request 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh 
ACCEPT     udp  --  anywhere             anywhere            udp dpt:ssh 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:www 
ACCEPT     udp  --  anywhere             anywhere            udp dpt:www 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:https 
ACCEPT     udp  --  anywhere             anywhere            udp dpt:https 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpts:ftp-data:ftp 
ACCEPT     udp  --  anywhere             anywhere            udp dpts:20:fsp 
ACCEPT     tcp  --  anywhere             anywhere            tcp dpts:49152:65534 
ACCEPT     udp  --  anywhere             anywhere            udp dpts:49152:65534 

Chain FORWARD (policy DROP)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

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

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

wszytko działa ok ale gdy chcę dostać się po ssh na konsolę muszę czekać dobrą minutę zanim poprosi mnie o hasło podczas wydania komendy apt-get update jest to samo a czasem zdarza się nawet, że wywala

Błąd http://archive.ubuntu.com lucid Release.gpg
Tymczasowy błąd przy tłumaczeniu "archive.ubuntu.com"

Proszę was o radę co źle ustawiłem, co powinienem zmienić

Pozdrawiam serdecznie

PS. dodam tylko, że gdy zmienię INPUT na policy ACCEPT to wszystko śmiga aż miło

[snejk88]

Zaloguj się tak:

Kod: Zaznacz cały

ssh -vv user@server

i pokaż na czym wisi

[marcintpi]

Zaloguj się tak:

Kod: Zaznacz cały

ssh -vv user@server

i pokaż na czym wisi

Oczywiście sprawdzę to co napisałeś i dam tu wynik ale to jak wrócę do domu

Dodam tylko, że jak jestem zalogowany na konsolę i robię np ping jakiś tam adres to pingi nie lecą :/ wcześniej o tym nie napisałem, a może to podsunie jakiś pomysł

Polecenie

Kod: Zaznacz cały

ssh -vv user@server

daje
i tu wisi dobrą minutę :/ natomiast jak chcę puścić update to wisi jeszcze dłużej

Kod: Zaznacz cały

OpenSSH_5.5p1, OpenSSL 1.0.0d-fips 8 Feb 2011
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to domena.pl [adres IP] port 22.
debug1: Connection established.
debug1: identity file /home/marcin/.ssh/id_rsa type -1
debug1: identity file /home/marcin/.ssh/id_rsa-cert type -1
debug1: identity file /home/marcin/.ssh/id_dsa type -1
debug1: identity file /home/marcin/.ssh/id_dsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3p1 Debian-3ubuntu6
debug1: match: OpenSSH_5.3p1 Debian-3ubuntu6 pat OpenSSH*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_5.5
debug2: fd 3 setting O_NONBLOCK
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v00@openssh.com,ssh-dss-cert-v00@openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib@openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: none,zlib@openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_setup: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 140/256
debug2: bits set: 520/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Host 'e-ck.pl' is known and matches the RSA host key.
debug1: Found key in /home/marcin/.ssh/known_hosts:1
debug2: bits set: 545/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/marcin/.ssh/id_rsa ((nil))
debug2: key: /home/marcin/.ssh/id_dsa ((nil))

[abix_adamj]

Tutaj najważniejsze jest:

Tymczasowy błąd przy tłumaczeniu "archive.ubuntu.com"

To oznacza, że z pewnych przyczyn (jeszcze mi nieznanych) nie działa sprawnie resolver nazw DNS. A to jest częsta przyczyną długiego oczekiwania na logowanie poprzez ssh.

Podaj zawartość twojego pliku /etc/resolv.conf na tym serwerze, oraz dla testów kilka komend:

Kod: Zaznacz cały

route -n
ping  -c3 -w3 195.162.24.38
ping -c3 -w3 cutty-sark.abix.info.pl

Przykładowo u mnie wygląda to tak:

Kod: Zaznacz cały

adasiek@sea-star:~$ ping -c3 -w3 cutty-sark.abix.info.pl
PING cutty-sark.abix.info.pl (195.162.24.38) 56(84) bytes of data.
64 bytes from cutty-sark.abix.info.pl (195.162.24.38): icmp_req=1 ttl=55 time=60.7 ms
64 bytes from cutty-sark.abix.info.pl (195.162.24.38): icmp_req=2 ttl=55 time=89.1 ms
64 bytes from cutty-sark.abix.info.pl (195.162.24.38): icmp_req=3 ttl=55 time=78.9 ms

--- cutty-sark.abix.info.pl ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2000ms
rtt min/avg/max/mdev = 60.723/76.275/89.118/11.751 ms

I wtedy zobaczymy....
Adam

[marcintpi]

Oczywiście podam komendy o których mówiłeś ale jest to vps by była jasność bo teraz patrze i nie napisałem o tym za co przepraszam i jest taka sprawa, że jak iptables zmienię na ACCEPT to nie ma tego problemu więc czy winy można szukać w dns-ach ?

[snejk88]

A dlaczego nie dodałeś do firewalla regułki akceptującej połączenia zestawione przez serwer i powiązane?

Kod: Zaznacz cały

iptables -I INPUT -p ALL -m state --state RELATED,ESTABLISHED -j ACCEPT

I może spróbuj dodać do sshd_config:

Kod: Zaznacz cały

UseDNS no

[marcintpi]

snejk88 dzięki za rade dodałem to co napisałeś łączenie po ssh przyspieszyło ale jeżeli chodzi o aktualizację czyli apt-get update z konsoli dalej wisi :/

[snejk88]

Wisi przy apt-get update? A przy wyłączonym firewallu jest ok? Pokaż:

Kod: Zaznacz cały

iptables -L
[code]

cat /etc/resolv.conf[/code]
No i napisz przy wykonywaniu czego 'wisi'

[marcintpi]

Wisi przy apt-get update? A przy wyłączonym firewallu jest ok? Pokaż:

Kod: Zaznacz cały

iptables -L
[code]

cat /etc/resolv.conf[/code]
No i napisz przy wykonywaniu czego 'wisi'

resolv.conf

Kod: Zaznacz cały

nameserver 91.203.134.60
nameserver 193.143.121.3

iptables -L podawałem na początku + to co podałeś dopisałem

przy wyłączonym firewallu jest ok

Przy uruchomionym iptables w ogóle pingi nie idą na jakąkolwiek domenę czy adres ip

[snejk88]

Musisz zezwolić na przychodzące odpowiedzi echa.

Kod: Zaznacz cały

iptables -I INPUT -p icmp --icmp-type echo-reply -j ACCEPT