netfilter/iptables FAQ
Harald Welte <laforge@netfilter.org>
Fordította Kis-Szabó András <kisza@sch.bme.hu>
Version $Revision: 566 $, $Date: 2003-12-23 20:18:45 +0100 (mar, 23 dic 2003) $
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@netfilter.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:
�,
�.
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.