A CVS fán belül lakik a tesztrendszer: amit nyújtani tud, az nagyobb biztonság arra vonatkozóan, hogy a változtatásaid nem rontottak el semmit. Triviális tesztek legalább annyira fotosak, mint a trükkösek: az egyszerû tesztek leegyszerûsítik az összetetteket (legalábbis biztos lehetsz benne, hogy az egyszerûbb dolgok mûködnek, mielõtt belekezdesz az összetettekbe).
A tesztek egyszerûek: csak shell-scriptek a testsuite/ könyvtárban, amiknek sikeresen le kell futniuk. A scriptek ABC-sorrendben futnak, így a `01test' a `02test' elõtt hajtódik végre. Jelenleg 5 könyvtár van:
Általános Netfilter tesztek
iptables tesztek
connection tracking tesztek
NAT tesztek
ipchains/ipfwadm kompatibilitási tesztek
A testsuite/ könyvtárban található a `test.sh'. Ez elkészít két dummy interface-t (tap0 és tap1), felkapcsolja a forwardingot, s kitölt minden netfilter modult. Ezután végighalad a fenti könyvtárakon, s elindítja a test.sh scriptjeiket, egészen addig, míg az egyik hibát nem jelez. Két argumentuma van: `-v'-re kiírja az összes tesztet végrehajtáskor, míg egy teszt nevének megadásával addig kihagy minden tesztet, míg meg nem találja a megadottat.
Készíts egy új file-t a megfelelõ könyvtárban: próbáld meg beszámozni a tesztedet, hogy a helyes idõben fusson le. Pl: az ICMP válasz teszteléséhez (02conntrack/02reply.sh) meg kell gyõzõdnünk a kérés helyes kezelésérõl (02conntrack/01simple.sh).
Jobb sok kis tesztet készíteni, ahol mindegyik lefed egy adott területet, mert segíti a probléma helyének pontos meghatározását.
Ha hibát észlelsz, egyszerûen lépj ki `exit 1'-el, ami hibajelzést generál; ha valami, amit vizsgálsz hibát kell hogy jelezzen, akkor célszerû egy egyedi üzenet megjelenítése. A teszted `exit 0'-val lépjen ki, ha minden sikeres volt. Minden parancs sikerességét ellenõrizni kell, akár a `set -e' használatával, akár egy `|| exit 1' kiegészítéssel minden parancs után.
A segédfunkciók (`load_module' és `remove_module') használhatók a modulok kezelésére: sose támaszkodj az automatikus betöltésre, kivéve, ha valójában azt szeretnéd tesztelni.
Két játék interface-ed van: tap0 és tap1. A címük a $TAP0 és
$TAP1 válozóban található. Mindkettõ netmaskja 255.255.255.0; a
hálózati címük a $TAP0NET-ben és a $TAP1NET-ben található.
Van egy üres ideiglenes file-od a $TMPFILE-ban. Ez törlésre kerül a teszted végén.
A tesztjeid a testduite/ könyvtárból fognak futni. Ezentúl ha programokat szeretnél használni, akkor azokat a `../userspace' path-stringgel használd.
A scipted bõvebb információt is megjeleníthet, ha a $VERBOSE be van állítva (a felhasználó megadta a `-v' kapcsolót).
Számos hasznos segédprogramot találsz a "tools" könyvtárban: mindegyik nem-nulla visszatérési értékkel jelzi, ha valamilyen problémája akadt.
IP csomagokat tudsz a segítségével elõállítani, amelyek a kimeneten fognak megjelenni. A csomagokat bele tudod küldeni a tap0 és tap1 eszközökbe egyszerû kimenet-átirányítással a /dev/tap0 ill. /dev/tap1-re (ezeket a testsuite elsõ futáskor létrehozza, ha nem léteztek korábban).
gen_ip egy nagyon egyszerû program, ami igen kényes a paraméter-sorrendjére. Elõször az általános opciók jönnek:
Elkészíti a csomagot, és darabokra tördeli a megadott hosszal és eltolással.
Beállítja a `More Fragments' bitet a csomagban.
Beállítja a forrás MAC címet a csomagban.
Beállítja a TOS mezõt (0-255).
Ezután jönnek a kötelezõ paraméterek:
Forrás IP cím.
Cél IP cím.
Teljes hossz, a fejlécet beleszámolva.
A protokoll sorszáma, pl. 17 = UDP.
Az ezután következõ paraméterek protokoll-függõek: az UDP(17)-hez a forrás és a cél portszám; az ICMP(1)-hez a típus és a kód: ha a típus 0 vagy 8 (ping-válasz, vagy ping), akkor két további argumentumot vár (az ID és a sequence mezõk). A TCP-hez a forrás és célport, és a flagek ("SYN", "SYN/ACK", "ACK", "RST" vagy "FIN"). Itt lehetõség van három további argumentumra is: "OPT=" - vesszõvel elválasztott opció-felsorolás, "SYN=" egy sequence number-rel, valamint "ACK=" szintén egy sequence number-rel. Végül egy opcionális argumentum, a "DATA" jelzi a csomag tartalmát, amit a standard inputról tölt fel.
Az IP csomagokat tudod vele ellenõrizni. Amennyire csak lehetséges, megpróbálja visszaállítani a gen_ip parancssorát (a fragmentek a kivételek).
Nagyon hasznos a csomagok feldolgozásában. Két kötelezõ argumentuma van:
A maximális idõ másodpercben, amíg a csomag megérkezésére vár a tandard input-ján.
Az értelmezendõ csomagok száma.
Egy opcionális argumentuma van: a "DATA". Ennek hatására kinyomtatja a csomag tartalmát a kimenetére a fejléc után.
Egy általános felhasználási mód:
# Set up job control, so we can use & in shell scripts.
set -m
# Wait two seconds for one packet from tap0
../tools/rcv_ip 2 1 < /dev/tap0 > $TMPFILE &
# Make sure that rcv_ip has started running.
sleep 1
# Send a ping packet
../tools/gen_ip $TAP1NET.2 $TAP0NET.2 100 1 8 0 55 57 > /dev/tap1 || exit 1
# Wait for rcv_ip,
if wait %../tools/rcv_ip; then :
else
echo rcv_ip failed:
cat $TMPFILE
exit 1
fi
Egy csomagot vár (pl. a gen_ip-tól) a bemenetén, s ICMP error üzenetre fordítja.
Három argumentuma van: a forrás IP cím, típus és kód. A cél IP cím a csomag forráscíme lesz.
A bemenetén érkezõ csomagot elküldi a rendszerbe egy raw-socketen keresztül. Ez biztosítja a helyileg generált csomagot a tesztekhez (elválasztva a hálózati meghajtókba küldött csomagoktól, amik távolról érkezõnek látszanak).
Minden tool feltételezi, hogy mindet meg tud csinálni egy írással vagy olvasással: ez igaz az ethertap device-okra, de nem biztos, hogy igaz ha valami trükköset csinálsz a pipe-okkal.
dd-t lehet használni a csomagok darabolására: dd-nek van egy obs (kimeneti blokkméret) opciója, ami lehetõvé teszi a csomagok egy íráson keresztül való megjelenítését.
Elõször a sikerességre tesztelj: pl. teszteld azt, hogy a csomag sikeresen lockolásra került. Elsõ teszt legyen az, hogy a csomag normálisan áthaladt, s utána teszteld csak a blokkolást. Különben egy nem kívánt hiba megállíthatja a csomagokat...
Próbálj meg precíz teszteket írni, s ne véletlen dolgokkal tesztelj, s figyeld, mi lesz belõle. Ha egy pontos teszt hibát jelez, akkor a hiba helye használható információt adhat. Viszont ha egy véletlen teszt hibázik, akkor nem lehet vele mit kezdeni.
Ha egy teszt üzenet nélkül jelez hibát, használhatod a `-x' opciót a legelsõ sorban (pl: `#! /bin/sh -x'), hogy lásd, hogy melyik programok futnak.
Ha a teszt véletlenszerûen áll meg, ellenõrizd a külsõ behatásokat (próbáld meg leállítani a külsõ interface-eidet). Például Andrew Tridgell-el közös hálózaton ülve felfigyeltem, hogy Windows broadcast-el gyötörték a gépemet.