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
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!
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/.
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!
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.
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
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
Minden elérhetõ IP tábla kilistázódik a következõ paranccsal:
cat /proc/net/ip_tables_names
Ismert hiba. Kérlek updatelj a legutóbbi CVS-re, vagy használj 1.2.1-nél újabb iptablest, amint elérhetõ lesz!
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.
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).
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
httpd_accel_single_host off
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.
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
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.