netfilter/iptables FAQ Harald Welte Fordította Kis-Szabó András ______________________________________________________________________ Table of Contents 1. Általános kérdések 1.1 Honnan szerezhetem meg a netfilter/iptables-t? 1.2 Létezik a Netfilter-nek Linux 2.2.x-re vissza-portolt változata? 1.3 Létezik ICQ conntrack/NAT segédmodul? 1.4 Hova kerülnek a ip_masq_vdolive / ip_masq_quake / ... modulok? 1.5 Miről is szól ez a patch-o-matic, s hogyan tudom használni? 1.6 Hol találom az ipnatctl-t és több információt róla? 2. Problémák a fordítási folyamat alatt 2.1 Nem tudom lefordítani az iptables-1.1.1-et 2.4.0-test4-el és újabb kernellel 2.2 Nem tudom lefordítani az iptables 1.1.0-t a legutóbbi kernellel (>= 2.3.99-pre8) 2.3 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. 2.4 ipt_BALANCE, ip_nat_ftp, ip_nat_irc, ipt_SAME, ipt_NETMAP nem fordul le 2.5 Alan Cox 2.4.x-acXX sorozatú kernelét használom és problémákat tapasztaltam 3. Futási problémák 3.1 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> 224.bbb.bbb.bbb 3.2 NAT: X dropping untracked packet Y Z aaa.aaa.aaa.aaa -> bbb.bbb.bbb.bbb 3.3 Nem vagyok képes a Netfilter-t együtt használni a Linux bridging kódjával! 3.4 Az IRC modul nem tudja kezelni a DCC RESUME parancsot 3.5 Hogyan működik az SNAT több címre? 3.6 ip_conntrack: maximum limit of XXX entries exceeded 3.7 Hogyan listázhatom ki az összes követett / elmaszkolt kapcsolatot, a 2.2.x-ben megszokott 'ipchains -L -M'-hez hasonlóan? 3.8 Hogyan tudom kilistázni az összes elérhető IP táblát? 3.9 iptables-save / iptables-restore iptables-1.2-ben segfault-ol 3.10 iptables -L -nek nagyon sokáig tart kilistázni a szabályokat 3.11 Hogyan akadályozhatom meg a LOG targetet a konzolra való naplózástól? 3.12 Hogyan készítsek transzparens proxy-t squid és iptables segítségével? 3.13 Hogyan használjam a LOG targetet / Hogyan tudom egyszerre használni a LOG és DROP funkciókat? 3.14 kernel: Out of window data xxx 3.15 Miért tartja meg a kapcsolatkövetési rendszer az UNREPLIED kapcsolatokat magas időtúllépéssel? 4. Kérdések a Netfilter fejlesztéséről 4.1 Nem értem, hogy miként kell használni a QUEUE targetet userspace-ből 4.2 Szeretnék hozzájárulni a kódhoz, de nincs ötletem, hogy mivel 4.3 Kijavítottam egy hibát, elkészítettem egy bővítést. Hogyan publikálhatom? ______________________________________________________________________ 1. Általános kérdések Ez a fejezet az általánosan előforduló netfilter (és nem netfilter) vonatkozású kérdéseket tartalmazza. 1.1. 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 . 1.2. 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! 1.3. 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. 1.4. 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'. 1.5. 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. 1.6. 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! 2. Problémák a fordítási folyamat alatt 2.1. 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! 2.2. 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! 2.3. 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! 2.4. 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. 2.5. 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. 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: ˇ 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! 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: . 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 kapcsola- tot, 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: ˇ 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 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. 4. Kérdések a Netfilter fejlesztéséről 4.1. 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 ( ) 4.2. 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. 4.3. Kijavítottam egy hibát, elkészítettem egy bővítést. Hogyan pub- liká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.