iptables + Etch i kernel 2.6.18-6-amd64

iptables + Etch i kernel 2.6.18-6-amd64 - czy to błąd?

TooMeeK - 24-11-2008 21:10
Powiedzcie mi czy to jest błąd?
Mam dwa serwery, w obu takie same procesory, podobne płyty główne i ilość RAM.
Różnica polega na wersji Debiana - w jednym jest 32-bit, w drugim 64-bit.
Na obu zainstalowane wszystkie możliwe aktualizacje (system instalowany na podstawowych pakietach więc żadnych X-ów, tylko to co niezbędne).

Problem pojawia się po edycji /etc/ssh/sshd_conf.
Na 32-bitowej wersji po otwarciu w iptables portu dla przykładu 2345 i restarcie firewalla oraz serwisu ssh wszystko śmiga. Mogę podłączyć się do serwera lokalnie jak i zdalnie na tym porcie.
Natomiast w przypadku wersji 64-bitowej nie mogę połączyć się zdalnie (connection refused), a lokalnie owszem. Odkryłem, że dzieje się to na dowolnym 4-cyfrowym porcie. Gdy zmieniłem go na 18 to dopiero zaczęło działać.

W czym tkwi problem? Mnie to wygląda na jakiś błąd w SSH lub IPTABLES w wersji 64-bit, bo robiłem wszystko identycznie na obu serwerach (i to zdalnie). Tylko do tego drugiego później nie mogłem się już podłączyć.

Debian 4.0 Etch,
2.6.18-6-amd64 kernel,
iptables v1.3.6

fenix23 - 25-11-2008 11:57
a próbowałeś potem wejść przez standardowy port ? może zmiany się nie zapisały. No i może iptables jakoś nie przepuszcza tego ? A na koniec jest jeszcze plik /etc/hosts.allow i deny ale to tak tylko teoretycznie bo według opisu nie były one modyfikowane.

Na Twoim miejscu bym przebugował problem. Zmień najpierw port używany przez ssh i ustaw iptables aby wszystko przepuszczał. Będziesz wiedział czy problem leży po stronie ssh czy iptables. PS: upewnij się że ssh w ogóle się podnosi po zmianie konfiguracji bo może jakiś krzaczek przez pomyłke wprowadziłeś.

Pozdrawiam

TooMeeK - 25-11-2008 12:46
Więc tak: gdy zmieniłem z powrotem na standardowy port SSH już nie działało, lokalnie owszem ale nie przez internet. Czyściłem regułki IPTABLES żeby wpuścić cały ruch i też nie działało (tylko lokalnie).

Adres publiczny przydzielony od dostawcy - jeden z pięciu od DSL. ps -A | grep ssh - podaje mi że SSH chodzi, dziwne jest to że nawet próbując np. telnet 192.168.1.1 25 z innego komputera nie da się podłączyć do serwera choć port jest otwarty i Exim chodzi.
Podobnie nmap -A localhost wydane na serwerze nie chciał mi nic wyświetlić. Tak jakby wszystkie porty zostały zablokowane przez IPTABLES. A ponieważ wcześniej wszystko było dobrze i nic nie zmieniałem w firewallu oprócz tego portu to mnie to mocno zdziwiło. Na 32-bitowej wersji wszystko jest poprawnie. W 64-bitowej po zmianie portu SSH na 18 działa, a wcześniej gdy miałem ustawione dla SSH 2345 serwer był martwy i zdalnie w ogóle nie odpowiadał.

Firewall wzorowany na:
http://www.debian.org/doc/manuals/se...rvices.en.html

fenix23 - 25-11-2008 12:55
to wrzuć nam jeszcze:
iptables -t nat -L

TooMeeK - 25-11-2008 13:13
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp -- anywhere host.internetdsl.tpnet.pl tcp dpt:3389 to:192.168.0.59:3389
DNAT tcp -- anywhere host.internetdsl.tpnet.pl tcp dpt:5000 to:192.168.0.59:5000
DNAT tcp -- anywhere anywhere tcp dpt:www to:192.168.0.58:8080

Chain POSTROUTING (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination 192.168.0.1 - to serwer NND, bramka internetowa, do którego podpięty jest DSL
192.168.0.58 - to adres mojego serwera w sieci LAN, chodzi na nim SQUID, jak widać.
192.168.0.59 - to jeden z komputerów, na który zrobiłem sobie przekierowanie.

Kolega zarządzający bramką powiedział, że wszystkie porty na mój adres są przekierowane z jednego z 5 dostępnych adresów publicznych jemu przydzielonych i faktycznie to działało do czasu aż zacząłem zmieniać port dla SSH.

fenix23 - 25-11-2008 17:49
Może problem leży na bramce, a nie na serwerze. Z sieci lokalnej też jest problem czy tylko z zewnętrznego IP? Próbowałeś przez ten adres łączyć się z 192.168.0.58?

Może koleś na bramce routuje tylko pierwsze 1024 porty?