# [SOLVED] Źle działający internet w 2.6.20-gentoo-r6 i r7

## LinuxTux

Otóż mam taki problem. Po aktualizacji jądra do wersji 2.6.20-gentoo-r6 (r7 też dotyczy), nie działa poprawnie internet tj. nie mogę się połączyć z żadnym serwerem. Wywala w Firestarterze w karcie Events, ip hostów oraz porty (na ogół wysokie) do których chcę się podłączyć.

eth0 tak jak cały system wstaje poprawnie. Jądro aktualizowałem przez skopiowanie starego configu do nowego katalogu kernela i wydałem polecenie make oldconfig. Co zrobiłem źle?Last edited by LinuxTux on Tue May 01, 2007 8:49 pm; edited 2 times in total

----------

## arek.k

Nigdy nie korzystałem z make oldconfig, więc nie wiem co dokładnie robi (szczegóły działania) i szczerze mówiąc nie chce mi się szukać. Kolejne wersje jądra są dozyć znacznie modyfikowane, więc skopiowanie configa może nie dało prawidłowego efektu (zależy z której wersji upgradeowałeś i ile razy szedłeś już droga na skróty). Może lepiej było by skasować ten skopiowany .config (np. mv /usr/src/linux/.config /usr/src/linux/.config_cp), a później ręcznie skonfigurowac jądro na podstawie configa z poprzedniego jądra (przez make menuconfig).

Jeśli uważasz, że nie jest to konieczne, to powiedz:

1. nie działa ci tylko internet, czy sieć wogóle (np. lokalna)

2. wspominasz o firestarterze. Na początek go wyłącz 

```
# /etc/init.d/firestarter stop
```

 i sprawdź, czy to coś zmienia. Z zaporą nie ma co panikować, ale jeśli już chcesz, możesz na ten czas wyłączyć wszystkie (zbędne) serwery (usługi).

Możesz tez dać wyniki: 

```
# ifconfig

# route
```

Sprawdź też ping ip (zamiast nazwa), np. ping 72.14.221.104.

Z twojego opisu ciężko mi wywnioskować coś konkretnego.

----------

## LinuxTux

Bez firestartera internet działa bez zarzutu. Przy próbie uruchomiania go z konsoli (normalnie startuje razem z gnome) wywala takie coś:

```
tux2 misiek # /etc/init.d/firestarter start

 * Starting Firestarter ...

iptables: No chain/target/match by that name

iptables: No chain/target/match by that name

iptables: No chain/target/match by that name

iptables: No chain/target/match by that name

Bad argument `137'

Try `iptables -h' or 'iptables --help' for more information.

Bad argument `137'

Try `iptables -h' or 'iptables --help' for more information.

Bad argument `138'

Try `iptables -h' or 'iptables --help' for more information.

Bad argument `138'

Try `iptables -h' or 'iptables --help' for more information.

Bad argument `5154'

Try `iptables -h' or 'iptables --help' for more information.

Bad argument `5154'

Try `iptables -h' or 'iptables --help' for more information.

iptables: No chain/target/match by that name

iptables: No chain/target/match by that name

Firewall started                                                          [ ok ]
```

```
tux2 misiek # ifconfig

eth0      Link encap:Ethernet  HWaddr xx:xx:xx:xx:xx:xx  

          inet addr:192.168.xxx.xx  Bcast:192.168.xxx.255  Mask:255.255.255.0

          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1

          RX packets:1867 errors:0 dropped:0 overruns:0 frame:0

          TX packets:795 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:1000 

          RX bytes:407028 (397.4 Kb)  TX bytes:107045 (104.5 Kb)

          Interrupt:16 Base address:0xe800 

lo        Link encap:Local Loopback  

          inet addr:127.0.0.1  Mask:255.0.0.0

          UP LOOPBACK RUNNING  MTU:16436  Metric:1
```

```
tux2 misiek # route 

Kernel IP routing table

Destination     Gateway         Genmask         Flags Metric Ref    Use Iface

192.168.xxx.0   *               255.255.255.0   U     0      0        0 eth0

loopback        *               255.0.0.0       U     0      0        0 lo

default         192.168.xxx.1   0.0.0.0         UG    0      0        0 eth0

          RX packets:1633 errors:0 dropped:0 overruns:0 frame:0

          TX packets:1633 errors:0 dropped:0 overruns:0 carrier:0

          collisions:0 txqueuelen:0 

          RX bytes:1372357 (1.3 Mb)  TX bytes:1372357 (1.3 Mb)
```

----------

## arek.k

Wynika z tego, że jest to wina zapory iptables. Jak startuje sam (automatycznie z gnome) to nie znaczy, że się nie wywala. Po prostu tego nie widzisz.

Czy działa ci bez problemu ze starym jądrem?

Albo nie wkompilowałeś czegoś w jądro (sporo się pozmieniało ostatnio w jądrze jesli chodzi o iptables), albo coś pochrzaniłeś w regułkach (konfiguracji firestartera).

Jak chcesz, możesz dać  wynik 

```
# iptables -L
```

 (po uruchomieniu firesartera) chociaż firestarter penie robi taką sieczkę, że i tak nikomu nie będzie się chciało analizować.

Moje zdanie na ten temat jest takie - skonfiguruj jądro ręcznie na podstawie configa ze starego jądra (żmudne, ale na pewno podziała jeśli prawidłowo przeniesiesz konfiguracje) chyba, że masz pewność co do poprawnego działania make oldconfig.

Po drugie, spróbuj zupgradeować firestartera, potworzyć regułki od nowa. Może to coś pomoże.

No i jeszcze jedno. Czy masz aż tak skomplikowaną sytuację (sieć-usługi) i nie potrafisz skonfigurować iptables "ręcznie", że korzystasz z firestartera? Kiedyś też do niego się zabierałem, ale jego działanie tak mnie zniechęciło (może to moja niekumatość, czy coś takiego), że w końcu nauczyłem sie podstaw (tych najbardziej elementarnych reguł) iptables i teraz mam spokój, bo wszystko (z tego co mam) rozumiem.

Korzystanie z "czystego" iptables nie jest aż tak skomplikowane (chyba). Przykładowo (może nie szczyt finezji, ale chyba nie ma rażących błędów w moim rozumowaniu): 

```
#czyszczenie reguł

iptables -F 

#Domyślna polityka

iptables -P INPUT ACCEPT #akceptacja przychodzących

iptables -P OUTPUT ACCEPT #akdeptacja wychodzących

iptables -P FORWARD DROP #upuszczanie przekierowania portów

# otwarcie wszystkiego na sieć lokalną bez ograniczeń

iptables -A INPUT -i eth0 -s 192.168.1.0/24 -j ACCEPT

# akceptacja przychodzących na porcie 22

iptables -A INPUT -i eth0 -p tcp --dport 22 -j ACCEPT #(na eth0, ptotokół tcp, port 22 - ssh)

# upuszczanie nowych połączeń (aby zablokowac wszystko z domyślej polityki INPUT ACCEPT)

iptables -A INPUT -i eth0 -m state --state NEW -j DROP

```

Znaczenie opcji -i, -s -j, itd. można sprawdzić w man iptables. Regułki po domyślnej polityce wydają się być w dziwnej kolejności. Wynika to z tego, że -A powoduje umieszczenie regułki na "końcu listy", a iptables przetwarza właśnie regułki od końca (w uproszczeniu). Czyli wynik powyższego, to coś w stylu listy reguł: 

```
# iptables -L

Chain INPUT (policy ACCEPT)

target     prot opt source               destination

ACCEPT     all  --  192.168.1.0/24       anywhere

ACCEPT     tcp  --  anywhere             anywhere            tcp dpt:ssh

DROP       all  --  anywhere             anywhere            state NEW

Chain FORWARD (policy DROP)

target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)

target     prot opt source               destination
```

jak to prześledzisz (pamiętając, że jedziesz od dołu  :Wink:  i oddzielnie dla każdego chain'a), to zauważysz, że dodawane są coraz większe uprawnienia dla coraz węższej grupy (klientów).

Bardziej intuicyjne jest -I (zamiast -A), bo umieszcza regułkę na górze listy (czyli do powyższego listingu będą dochodziły regułki na górę listy, zamiast na dół, jak to miało miejsce przy -A).

Jednym słowem zachęcam do stosowania iptables (zamiast tych "ułatwiaczy"), bo tak jest wbrew pozorom łatwiej.

Oczywiście @Raku jak to zobaczy (jako spec od routerów linuxowych) pewnie po mnie porzadnie pojedzie za to, co tu nawypisywałem i pewnie będzie miał rację, ale mam nadzieję, że to ci w jakiś sposób pomoże.

Jeszcze mi się przypomniało: ip 192.168.xxx.xxx możesz śmiało podawać, bo są to adresy dla sieci lokalnej (nikt z zewnątrz się po nich nie dobierze, jesli nie podawałeś z tego powodu). Posługując się takim ip można co najwyżej (przy odrobinie) szczęscia włamać się na swój własny komputer.

----------

## Johnny_Bit

Nowy kernel ignoruje stare ustawienia dot. netfiter. przekonałem się o tym sam, ale nada nie jestem pewien czy wszystko ustawiłem tak jak byo...

----------

## LinuxTux

Niby wkompilowałem to co trzeba do kernela i nadal ten sam problem.

PS. Jest jakaś inna nakładka na iptables? Może być nawet pod konsole.

----------

## timor

 *LinuxTux wrote:*   

> Niby wkompilowałem to co trzeba do kernela i nadal ten sam problem.
> 
> PS. Jest jakaś inna nakładka na iptables? Może być nawet pod konsole.

 Mam analogiczny problem z czystym iptables, w nowym jaju brakuje mi jednego modułu (STATE), z którego dość intensywnie korzystam. Szukałem już pomoc na kilku wątkach, np. https://forums.gentoo.org/viewtopic.php?p=4031528#4031528.

Nadal nie mam żadnego rozwiązania.

----------

## arek.k

@timor, a jaka była (w starszych kernelach) pełna nazwa tego modułu, o który ci chodzi?

Pytam, bo nie jestem pewien, ale jeśli chodzi ci i  IP_NF_MATCH_STATE (ze starego jądra) to w nowym ( 2.6.20-gentoo-r3) jest to IMHO NETFILTER_XT_MATCH_STATE (chyba, że w jeszcze nowszych wersjach coś się zmieniło).

----------

## timor

Dzięki za zwrócenie uwagi, w konfigu kernela nastąpiła migracja kilku opcji, nowa grupa itd.... 

Mam już działające rozwiązanie. Dla osób, którym potrzebny jest moduł state. Opcja wyboru pokazuje się dopiero po uaktywnieniu:

```
Networking  --->

Networking options  --->

 [*] Network packet filtering framework (Netfilter)  --->

      Core Netfilter Configuration  --->

          <M> Netfilter connection tracking support
```

I wtedy zaznaczam sobie:

```
<M>   "state" match support
```

Również dopiero wtedy pokazuje się opcja dla modułu conntrack:

```
<M>   "conntrack" connection tracking match support
```

Po tym jeszcze wywalały mi się dziwne błędy (iptables: Invalid argument) ale po dodaniu:

```
Networking -->

Networking options -->

Network packieg filtering framework (Netfilter) -->

IP: Netfilter Configuration -->

<*>IPv4 connection tracking support (required for NAT)
```

wszystko jest OK.

----------

## LinuxTux

Działa! Dzięki ci timor.

A te błędy:

```
Bad argument `{numer_portu}'

Try `iptables -h' or 'iptables --help' for more information. 
```

są spowodowane przez ustawienie w firestarterze "lan" dla regułek. Żeby to rozwiązać polecam ustawienie "everyone". Teraz już wiem dlaczego nie działała gra bzflag w trybie multiplayer.

Jeszcze raz dzięki.

----------

