Next Previous Contents

3. Futási problémák

3.1 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb

Ezt az üzenetet a NAT küldi, mert egy multicast csomag érte el a NAT táblát, és a kapcsolatkövetés jelenleg még nem kezeli a multicast csomagokat. Abban az esetben, ha nincs ötleted, hogy mi okozza a multicastot, vagy nincs rá szükséged, akkor:

iptables -t mangle -I PREROUTING -j DROP -d 224.0.0.0/8

3.2 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

A syslogom vagy a konzolom a következõ üzenetet tartalmazza:

NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb

Az üzenetet a NAT rész küldi. Eldobja a csomagot, mivel a NAT-hoz valós kapcsolati információknak kell lenniük a csomaghoz. Ez az üzenet minden csomagnál kiírásra fog kerülni, ahol a connection tracking modul nem tudta meghatározni a kapcsolatinformációt.

Lehetséges okok:

Ha még részletesebb naplózásra van szükséged ezekrõl a csomagokról (pl. azt feltételezed, hogy távoli próbálkozások / scannelések), akkor a következõ szabályt használd:

iptables -t mangle -A PREROUTING -j LOG -m state --state INVALID

És igen, a mangle táblába kell elhelyezned a szabályt, mert a csomagok a NAT kód által kerülnek eldobásra, még mielõtt elérnék a filter táblát!

3.3 Nem vagyok képes a Netfilter-t együtt használni a Linux bridging kódjával!

Nos, egy teljesen átlátszó tûzfalat szeretnél építeni? Nagyszerû ötlet! A 2.4.16 esetében egy extra patch-csel módosítanod kell a kerneled, hogy mûködésre bírd a dolgot. A pacth-et megtalálod a következõ címen: http://bridge.sourceforge.net/.

3.4 Az IRC modul nem tudja kezelni a DCC RESUME parancsot

Nos, ez csak félig igaz. Csak a NAT modul nem tudja kezelni. Amennyiben csak tûzfalat használsz, NAT nélkül, akkor rendben fog mûködni!

3.5 Hogyan mûködik az SNAT több címre?

Netfilter megpróbál a lehetõ legkevesebbet változtatni. Ha egy újonnan indított gépünk van, és valaki az SNAT mögött egy kapcsolatot indít 1234-es portról, a Netfilter csak az IP-címet fogja megváltoztatni, s a port marad a régi.

Amint valaki más nyit még egy kapcsolatot azonos forrás-porttal, a Netfilter meg fogja változtatni az IP-t és a portot is, amennyiben csak egyetlen IP-je van SNAT-ra.

De ha több mint egy címet használhat, akkor ismét csak az IP-címet változtatja meg.

3.6 ip_conntrack: maximum limit of XXX entries exceeded

Ha a fenti üzenetet találod a syslog-ban, akkor az azt jelenti, hogy a kapcsolatkövetési adatbázis nem tartalmaz elég helyet a bejegyzéseknek a Te környezetedben. A kapcsolatkövetési modul alapértelmezésben adott számú párhuzamos kapcsolatot tud lekezelni. Ez a szám függ a rendszered maximális memóriaméretétõl ( 64MB: 4096, 128MB: 8192, ...).

Egyszerûen meg tudod növelni a maximálisan kezelhetõ kapcsolatok számát, de tartsd szem elõtt, hogy minden követett kapcsolat lefoglal 500 byte nem swapelhetõ kernel memóriát!

A határ 8192-re emeléséhez a következõt kell beírnod:

echo "8192" > /proc/sys/net/ipv4/ip_conntrack_max

3.7 Hogyan listázhatom ki az összes követett / elmaszkolt kapcsolatot, a 2.2.x-ben megszokott 'ipchains -L -M'-hez hasonlóan?

Van egy file a /proc-filerendszerben, amit /proc/net/ip_conntrack-nek hívnak. A következõ paranccsal tudod megjeleníteni a tartalmát:

cat /proc/net/ip_conntrack

3.8 Hogyan tudom kilistázni az összes elérhetõ IP táblát?

Minden elérhetõ IP tábla kilistázódik a következõ paranccsal:

cat /proc/net/ip_tables_names

3.9 iptables-save / iptables-restore iptables-1.2-ben segfault-ol

Ismert hiba. Kérlek updatelj a legutóbbi CVS-re, vagy használj 1.2.1-nél újabb iptablest, amint elérhetõ lesz!

3.10 iptables -L -nek nagyon sokáig tart kilistázni a szabályokat

Ez azért van, mert az iptables DNS feloldást végez minden IP-címre. Minden szabály két címet is tartalmazhat, s ez a legrosszabb esetben két DNS-feloldást jelent minden szabálynál.

A gond az, ha privát IP-címeket (10.x.x.x vagy 192.168.x.x, ...) használsz, akkor a DNS nem tudja feloldani a hoszt-neveket, s timeout-ol. Ezeknek a timeout-oknak az összes ideje _nagyon_ sokáig is eltarthat, a szabályrendszered függvényében.

Kérlek, használd a -n (számok) opciót az iptables-hez, hogy megakadályozd a DNS névfeloldásokat.

3.11 Hogyan akadályozhatom meg a LOG targetet a konzolra való naplózástól?

Megfelelõen kell bekonfigurálnod a syslogod: A LOG target a kern facility-be logol warning(4) prioritással. A syslog.conf man oldalát tanulmányozd a facility és prioritások megértéséhez.

Alapértelmezésben, minden kernel üzenet, ami komolyabb mint a debug(7) a konzolon is megjelenik. Ha 4-re emeled a határt 7 helyett, akkor a LOG üzenetek többé nem jelennek meg a konzolon.

Figyelj azonban arra, hogy ez elnyomhat egyéb, fontos üzeneteket, amiknek meg kellene jelenniük a konzolon (ez nem érinti a syslog-ot).

3.12 Hogyan készítsek transzparens proxy-t squid és iptables segítségével?

Elõször természetesen szükséged van egy megfelelõ DNAT vagy REDIRECT szabályra. A REDIRECT-et csak akkor használd, ha a squid a NAT-oló eszközön van. Pl:

iptables -A PREROUTING -p tcp --dport 80 -j DNAT --to 192.168.22.33:3128

Ezután a squid-et kell megfelelõen bekonfigurálnod. Itt csak rövid megjegyzéseket tudunk tenni, légy szíves nézd meg a squid leírását a további információkért!

A squid.conf-nak (Squid 2.3-hoz) a következõkhöz hasonlókat kell tartalmaznia:

http_port 3128
httpd_accel_host virtual
httpd_accel_port 80
httpd_accel_with_proxy  on
httpd_accel_uses_host_header on
Squid 2.4 -nek szüksége van egy hozzáadott sorra:

httpd_accel_single_host off

3.13 Hogyan használjam a LOG targetet / Hogyan tudom egyszerre használni a LOG és DROP funkciókat?

A LOG target-et "nem-terminális target"-nek nevezzük, nem szakítja meg a csomag vándorlási útját. Ha a LOG targetet használod, akkor a csomag naplózásra kerül, majd folytatja útját a következõ szabállyal.

Nos, hogyan naplózzam az eldobott csomagot? Semmi sem egyszerûbb, mint ez. Egy egyedi chain-t készítesz, ami két szabályt tartalmaz:

iptables -N logdrop
iptables -A logdrop -j LOG
iptables -A logdrop -j DROP

Most mindig, amikor naplózni akarod az eldobott csomagokat, egyszerûen a "-j logdrop"-ot kell használnod.

3.14 kernel: Out of window data xxx

A tcp-window-tracking patchet használod a patch-o-matic-ból, ami a TCP folyamokhoz elfogadható csomagok követését végzi a sequence/acknowledgement számok, szegmens-méretek, stb. alapján. Amikor egy olyan csomagot érzékel, ami nem elfogadható (ablakon kívüli), INVALID-ként megjelöli és a fenti üzenetet küldi.

Újabb verziók logolják a csomagot, s hogy melyik feltételt sértették meg:

A legújabb verziókban a naplózás teljesen lekapcsolható sysctl-el:

echo 0 > /proc/sys/net/ipv4/netfilter/ip_ct_tcp_log_out_of_window

3.15 Miért tartja meg a kapcsolatkövetési rendszer az UNREPLIED kapcsolatokat magas idõtúllépéssel?

Nos, megnézted a /proc/net/ip_conntrack filet, s azt láttad, hogy az UNREPLIED kapcsolatok magas idõtúllépési értékkel (akár öt nap) szerepelnek benne, s az érdekel, hogy miért vesztegetjük a kopcsolatkövetési bejegyzéseket UNREPLIED kapcsolatokkal (amik nem is kapcsolatok)?

A válasz egyszerû: UNREPLIED bejegyzések ideiglenes bejegyzések, így amikor kifogyunk a kapcsolatkövetési bejegyzésekbõl (elérjük a /proc/sys/net/ipv4/ip_conntrack_max értéket), kitöröljük a régi UNREPLIED értékeket. Más szavakkal: ahelyett, hogy üres mezõet tartanánk fent, jobban járunk, ha néhány hasznos értéket megtartunk ameddig nincs szükségünk a helyére.


Next Previous Contents