netfilter/iptables FAQ Harald Welte <laforge@gnumonks.org> &nl; Fordította Kis-Szabó András&nl; Version $Revision: 529 $, $Date: 2002-07-26 22:19:42 +0200 (vie, 26 jul 2002) $ Ez a dokumentum a netfilter levelezési listán előfordult Gyakran Ismételt Kérdéseket tartalmazza. Kommenteket / kiegészítéseket / pontosításokat szívesen fogadunk, ezeket lehetőség szerint a FAQ követőjének kell címezni (Harald Welte <laforge@gnumonks.org>). Általános kérdések

Ez a fejezet az általánosan előforduló netfilter (és nem netfilter) vonatkozású kérdéseket tartalmazza. Honnan szerezhetem meg a netfilter/iptables-t?

A Netfilter és az IPtables integrálásra került a 2.4.x-es Linux kernel sorozatba. A legutolsó kernel verzió letölthető a -ról, valamint a mirror-okról.

Az 'iptables' felhasználói program elérhető a netfilter honlapján, ami a következő helyeken érhető el: , , , vagy . Létezik a Netfilter-nek Linux 2.2.x-re vissza-portolt változata?

Nem, jelenleg nincs. Azonban ha valaki el akarja kezdeni, nem lenne nehéz dolga a tiszta hálózati interface miatt.

Kérlek jelezd felénk, ha elkezdtél dolgozni ezen a területen! Létezik ICQ conntrack/NAT segédmodul?

Ha masquerading-ot használtál Linux 2.2-n, akkor mindig az ip_masq_icq modult kellett használnod a közvetlen kapcsolat eléréséhez két ICQ kliens között.

Senki sem implementálta újra a modult netfilterhez, mert az ICQ protokoll túlságosan csúnya :) Szerintem azonban csak idő kérdése, hogy legyen egy.

Rusty egyszer rámutatott arra, hogy csak olyan protokollokhoz tartozó modulok kerülnek bele a fő Netfilter csomagba, melyeknek van legalább egy free kliense és szervere. Az ICQ-hoz csak kliensek voltak elérhetők, így nem illeszkedett a feltételhez. Hova kerülnek a ip_masq_vdolive / ip_masq_quake / ... modulok?

Néhányuk nem szükséges, és egy másik részük jelenleg még nem lett portolva Netfilter-re. A Netfilter teljes kapcsolatkövetést végez az UDP-hez is, és egy időzítési szabályt alkalmaz, hogy lehetőleg minél kisebb mértékben zavarja meg a csomagokat, szóval néha a dolgok 'csak működnek'. Miről is szól ez a patch-o-matic, s hogyan tudom használni?

A 2.4.x-es kernelek a stabil sorozatot képezik, szóval nem tudjuk az aktuális fejlesztéseinket csak úgy hozzáadni a fő kernelhez. Minden saját programunk a Netfilter patch-o-matic-ben kerül kifejlesztésre és tesztelésre. Ha valamelyik ilyen szolgáltatást szeretnéd használni, akkor egy vagy több patch-et kell alkalmaznod a patch-o-matic-ból. A patch-o-matic-et megtalálod a legutolsó iptables csomagban (és a CVS-ben, természetesen), amit a netfilter honlapjáról letölthető.

patch-o-matic-nek jelenleg három opciója van: make pending-patches make most-of-pom make patch-o-matic

Az elsővel arról győződhetsz meg, hogy minden fontos hibajavítás (ami a kernel karbantartóinak már elküldésre került) megtalálható-e a kerneledben. A második `most-of-pom` e meleltt rákérdez azokra a funkciókra amelyek konfliktus nélkül alkalmazhatóak. A harmadik opció a `patch-o-matic` a valódi haladólknak van, akik látni szeretnék az összes patchet - de légy körültekintő, mert ütközéseket okozhatnak!

patch-o-matic-nek elegáns felhasználói felülete van. Próbáld ki: make patch-o-matic vagy ha a kerneled nem a /usr/src/linux-ban van, akkor: make KERNEL_DIR={a-kernel-konyvtarad} patch-o-matic persze az iptables-csomag legfelső könyvtárában. A patch-o-matic ellenőrzi minden patch-ről, hogy alkalmazható-e az installált kernelhez, vagy sem. Amennyiben egy patch alkalmazható, akkor egy kérdést tesz fel, ahol több információt tudsz kérni a patch-ről, alkalmazását tudod kérni, ki tudod hagyni a patch-et, ...

További információkat a path-o-matic-ról a metfilter-extensions-HOWTO-ban találsz. Hol találom az ipnatctl-t és több információt róla?

ipnatctl a NAT szabályok kezeléséhez volt használatos a nagyon korai fejlesztői verziójú Netfilter-ben a 2.3.x-es kernel-sorozathoz. Többé nem szükséges, így nem is elérhető. Minden funkciót maga az Iptables vett magára. Vess egy pillantást a NAT HOWTO-ra a Netfilter honlapon! Problémák a fordítási folyamat alatt

Nem tudom lefordítani az iptables-1.1.1-et 2.4.0-test4-el és újabb kernellel

Ez egy ismert probléma. Az a mechanizmus, amivel az alkalmazandó patch-eket választjuk ki, hibás. Próbáld a 'make build'-et a 'make' helyett.

Jobb megoldás: frissítsd fel az iptables-t iptables-1.1.2-re vagy újabbra! Nem tudom lefordítani az iptables 1.1.0-t a legutóbbi kernellel (>= 2.3.99-pre8)

Az iptables belső felépítése magváltozott. Upgradelj iptables >= 1.1.1 -re! Néhány patch-o-matic patch az iptables-1.2.1a-ből nem működik 2.4.4-es és újabb kernelekkel.

Kérlek használd az iptables-1.2.2 verziót vagy a Netfilter CVS-t! ipt_BALANCE, ip_nat_ftp, ip_nat_irc, ipt_SAME, ipt_NETMAP nem fordul le

Legnagyobb valószínűség szerint a ip_nat_setup_info függvényben van valami probléma.

Ha iptables <= 1.2.2 -t használsz, akkor alkalmaznod KELL a 'dropped-table' és az 'ftp-fixes' patch-eket.

Ha iptables > 1.2.2 -t vagy CVS verziót használsz, kérlek ne alkalmazd a 'dropped-table'-t, mart nem kompatibilis a BALANCE, NETMAP, irc-nat, SAME és talk-nat patch-ekkel. Alan Cox 2.4.x-acXX sorozatú kernelét használom és problémákat tapasztaltam

A Netfilter csapata Linus kernelére alapozta a fejlesztést, az -ac sorozat használata csak saját felelősségre támogatott. Futási problémák 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 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: a maximális kapcsolati-szám elérésre került a kapcsolati táblában nem tudta meghatározni az inverz utat (multicast, broadcast) kmem_cache_alloc meghiúsult (elfogyott a memória) válasz egy nem megerősített kapcsolatra multicast csomag (lásd a következő fejezetben) icmp csomag túl rövid icmp töredezett icmp checksum hibás

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! 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: . 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! 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. 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 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 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 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! 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. 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). 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 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. 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: ACK az alsó határ alatt (egy túlságosan későn érkezett ACK) ACK a felső határ felett (az elfogadott adat sose lett elküldve) SEQ az alsó határ alatt (újraküldött, de már nyugtázott adat) SEQ a felső határ felett (a fogadó ablakán túl van)

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 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. Kérdések a Netfilter fejlesztéséről Nem értem, hogy miként kell használni a QUEUE targetet userspace-ből

A libipq könyvtár a csomagok userspace-ben való kezelésére készült. Ehhez a részhez tartozó dokumentáció man oldalak formájában érhető el. Ehhez az iptables fejlesztői verzióját kell elkészítened és felinstallálnod: make install-devel aztán nézd meg a libipq(3)-t.

Szintén érdekes lehet a Perl illesztése a libipq-hoz, Perlipq: . A kapcsolat maga egy minta a könyvtár használatához.

Egyéb kódminták: testsuite/tools/intercept.c a netfilter CVS-ből ipqmpd () nfqtest, a netfilter-tools része () Jerome Etienne WAN szimulátora () Szeretnék hozzájárulni a kódhoz, de nincs ötletem, hogy mivel

A Netfilter core-team fenntart egy TODO listát, ahol felsorolja az összes kívánt változtatást / új funkciót. Anonymous CVS-el el tudod érni a listát, a leírást megtalálod a Netfilter honlapon. Egy alternatívaként -el is el tudod érni CVSweb használatával. Kijavítottam egy hibát, elkészítettem egy bővítést. Hogyan publikálhatom?

Ha publikálni szeretnéd, akkor küld el a netfilter-devel levelezési listára. A feliratkozási információk: . A patch elküldésének helyes módja: A tárgy [PATCH]-el kezdődik Az üzenet törzsébe kell beleágyazni, nem MIME-olni! cvs-megjegyzés/Changelog bejegyzés a diff-en kívül. `diff -u old new' formátum, az alapkönyvtáron kívülről (ti. -p1 -el alkalmazható legyen)

Ha egy új kiegészítést készítettél, vagy egy régi kiegészítéshez adtál egy új opciót, akkor egy jó ötlet a netfilter-extension-HOWTO-t is updatelni az új kibővítés/funkció leírásával. Ráadásul ez több felhasználót fog vonzani a kiegészítésedhez, amin keresztül több visszajelzéshez juthatsz.