Programování síťové služby Sniffer OSPFv2 a OSPFv3

Transkript

1 Dokumentace k projektu z předmětu ISA Programování síťové služby Sniffer OSPFv2 a OSPFv3 Dne 27. listopadu 2011 zpracovala: Kateřina Šímová, xsimov01@stud.fit.vutbr.cz Fakulta informačních technologií Vysoké učení technické v Brně

2 Obsah Úvod do problematiky - Protokol OSPF...3 Vlastnosti OSPF...3 Rozdíly mezi verzemi...3 Zprávy v OSPF a princip činnosti...4 Hello...4 Database Description...4 Link State Request...5 Link State Update...5 Link State Acknowledge...5 Návrh aplikace...6 Odchytávání packetů na síti...6 Rozpoznávání OSPF packetů...6 Tisk informací o OSPF packetech...6 Tisk topologické databáze...6 Implementace...7 Informace o programu myospfsniffer...7 Návod k použití...8 Literatura...9

3 Úvod do problematiky - Protokol OSPF OSPF je dnes nejčastěji používaný směrovací protokol. V této práci se budu zabývat jeho variantami OSPFv2 (IPv4) a OSPFv3 (IPv6). Rozdílům mezi nimi se budu věnovat níže. OSPF je zkratkou pro anglický název Open Shortest Path First, hledání nejkratší cesty. Je to link-state protokol (tedy využívá Dijkstrův algoritmus pro sestavování směrovací tabulky). Nejkratší cesta v tomto pojetí znamená cestu s nejlepším ohodnocením, které zohledňuje přenosové rychlosti na linkách na rozdíl od protokolů typu distance vector, jako je například RIP, které jako nejlepší cestu vybírají tu s nejméně hopy. Vlastnosti OSPF Při použití protokolu OSPF je celá síť rozdělena do jednotlivých oblastí (area) s kořenovou oblastí area 0 nebo taky area , na kterou jsou další oblasti navázány. Každý router v dané oblasti zná celou topologii oblasti, takže může všem routerům v ní odesílat zprávy. Děje se tak například při odesílání zprávy Hello, která se odešle na multicast (adresu pro IPv4 a FF02::5 pro IPv6). Takovéto hromadné odeslání zpráv, zejména typu LSA, může zahltit síť, a proto se aktualizace posílají podmíněně na rozdíl od RIP, kde se čeká na vypršení časovačů. Reaguje tak na změny rychleji. OSPF packety jsou zapouzdřené do IP packetů a uvozené OSPF hlavičkami. Hlavičky jsou uloženy ve strukturách ospf_hdr_4 a ospf_hdr_6 v hlavičkovém souboru. Za hlavičkami pak následují záznamy hello, databaze description, link state request, link state update, link state acknowledge. Rozdíly mezi verzemi OSPFv2 je používán od roku 1998 pro routery pracující s IPv4 adresami. V roce 2008 se začal používat protokol OSPFv3 pro funkčnost nad IPv6. Princip obou verzí je stejný. Liší se pouze v některých místech v struktuře, pořadí a velikostech přenášených informací. Rozdíly jsou snadno vidět na strukturách v hlavičkovém souboru (čísla v komentářích označují kolik je zabráno bajtů). Grafické zpracování viz [1]. OSPFv2 je popsáno v RFC 2328 a pro OSPFv3 je to dokument RFC

4 Zprávy v OSPF a princip činnosti Hello První zprávy, které se v oblasti rozešlou, jsou zprávy hello, které slouží k hledání sousedů. V hello packetu jsou neseny tyto informace: maska sítě, interval odesílání, priorita routeru, dead interval routeru, designated router a záložní designated router, dodatečné informace a různý počet adres aktivních sousedů. Pro tyto informace je v hlavičkovém souboru struktura hell_pck a hell_pck_6. Adresy aktivních sousedů, jsou čteny zvlášť. Database Description Tyto zprávy jsou odpověďmi při hledání sousedů a nesou v sobě informace o topologii oblasti. Obsahuje informace o samotném DBD packetu a dále je za ním připojen různý počet LSA záznamů. DBD záznam je stejný pro všechny routery v dané oblasti. DBD router je Designated routerem pro ostatní v oblasti. 4

5 Link State Request Po získání informace o topologii sítě router vyčkává, dokud v topologii neproběhne změna. V takovém případě je odeslána žádost na zaslání nových informací o topologii sítě (link state request). Packet OSPF typu LSR je složen z hlavičky OSPF a za ní následujícím různým počtem LRS záznamů. Link State Update Je odpovědí na LSR. Probíhá tedy také pouze po změně stavu topologické databáze. Nese různé množství LSA záznamů, různých typů, hned za OSPF hlavičkou, jako informaci routerům v oblasti. Link State Acknowledge Je potvrzením výměny informací mezi routery. Je souborem jednotlivých LSA záznamů připojených hned za OSPF hlavičkou. LSA záznamy se ukládají do topologické databáze. 5

6 Po získání potřebných informací se sestaví SPF strom, podle kterého se pak po výpočtu nejlepších cest sestaví směrovací tabulka. Návrh aplikace Při návrhu aplikace jsem problematiku rozdělila do několika dílčích problémů. Odchytávání packetů na síti Naslouchání na rozhraní přijatém z parametrů programu s využitím knihovny libpcap. Rozpoznávání OSPF packetů Zjišťování informací z IP hlavičky a následný výběr pouze OSPF packetů. Tisk informací o OSPF packetech Přistoupení k OSPF hlavičce. Vytvoření struktur pro hlavičky OSPF i pro jednotlivé zprávy. Tisknutí informací bude rozděleno do funkcí pro jednotlivé typy zpráv a jejich varianty pro IPv4 a IPv6. Tisk topologické databáze Vytištění topologické databáze po ukončení programu. Reakce na ukončující signál. Implementace Zvolila jsem implementaci v C++, bohužel jsem od začátku návrhu implementace nevyužila jeho objektový přístup, který, jak jsem později zjistila, by mohl mnohé věci zjednodušit, nebo alespoň urychlit. Například samotné vypisování informací. V rámci implementace bylo vytvořeno množství struktur v hlavičkovém souboru. Byly vytvořeny struktury pro hlavičky OSPF packetů a pro informace nesené jednotlivými zprávami (hello, DBD, LSR...). Vzhledem k odlišnostem ve verzi 2 a 3 musely být pro každý záznam vytvořeny 2 varianty. Při vytváření struktur jsem vycházela z RFC dokumentů [3][2]. Při jejich vypisování jsem se pak inspirovala programem Wireshark, který jsem použila i pro kontrolu výstupů. 6

7 Rozpoznání OSPF packetů přicházejících na rozhraní probíhá pomocí kontroly hodnoty type v IP hlavičce. Po té bylo třeba rozpoznat variantu OSPF protokolu. Pomocí přičtení k pointeru na IP hlavičku jsem se o velikost struktury IP hlavičky posunula v paměti na začátek OSPF hlavičky. Kde jsem přiložila vytvořenou strukturu pro OSPF hlavičku a zjistila typ zprávy, kterou packet nese a délku OSPF packetu. Podle toho se volají jednotlivé funkce pro tisknutí informací (pro IPv4 a IPv6 odlišné). Po zavolání funkcí jsem se obdobným způsobem posunula za OSPF hlavičku. Posléze se vypíší informace, kterých je fixní počet a pak následuje cyklus pro vypisování typů informací, kterých může být rozdílné množství. Cyklus běží a vypisuje tak dlouho, dokud nenarazí na konec packetu, který kontroluji porovnání čítače s délkou packetu, kterou jsem si zjistila dříve. Při tomto vypisování využívám pomocných funkcí, jako je například print_lsa_4, a funkce pro převod typů LSA záznamů z číselných údajů na text, například funkce type_to_string_4. Část s výpisem DB zatím nebyla dokončena. Informace o programu myospfsniffer Počet souborů: 2 Řádků kódu: 509 Řádků komentářů: 225 Velikost zdrojových souborů: 22 kb + 2,8 kb Velikost spustitelného souboru: 14 kb Návod k použití Nejprve přeložte zdrojový kód příkazem make. Poté program spusťte pomocí./myospfsniffer -i <rozhraní>. Dále jen sledujte výpis na stdout. Pro nápovědu spusťte program s parametrem -h (./myospfsniffer -h). 7

8 Literatura [1] Strech, Jeremy; OSPFv2 versus OSPFv3 [on-line], Citováno: < [2] Coltun, R., Ferguson, D., Moy, J.; RFC 5340 [on-line], Citováno: < [3] Coltun, R., Ferguson, D., Moy, J.; RFC 2328 [on-line], Citováno: < [4] Cisco Systems, CISCO prezentation [on-line], Citováno: < 0311e31.pdf> [5] pcap(3) - Linux man page [on-line], Citováno: < [6] Programming with pcap [on-line], Citováno: < [7] Matúš Lenhart, Nebojte se počítačových sítí, Seriál časopisu PC REVUE, srpen