OpenOSPFD kasutamine OpenBSDga
Sisukord
Sissejuhatus
Internet koosneb võrkude haldajatele usaldatud suurtest võrkudest, mida nimetatakse autonoomseteks süsteemideks (AS - Autonomous System). Üheks oluliseks ülesandeks nende võrkude pidamisel on ruutingute haldamine, reeglina räägitakse võrkude vahel EGP protokolli ja võrgude sees IGP protokolli.
- EGP (Exterior Gateway Protocol) - nt BGP4 (Border Gateway Protocol) protokoll ja implementatsioon OpenBGPD; BGP4 on 2009 aastal praktiliselt ainus levinud EGP
- IGP (Interior Gateway Protocol) - nt OSPF (Open Shortest Path First) protokoll ja impementatsioon OpenOSPFD; OSPF on 2009 aastal tõenäoliselt kõige levinum IGP; lisaks on palju kasutusel IS-IS (Intermediate System to Intermediate System) ja EIGRP (Enhanced Interior Gateway Routing Protocol), vähem RIP (Routing Information Protocol)
OSPF protokoll
Internet on jagatud haldusaladeks, iga haldusala haldab tavaliselt ISP või muu organisatsioon ning ühte sellist ala nimetatakse Autonomous System (AS)
AS5050 AS5051 AS5052
Tavaliselt arvutatakse ruutinguid IGP (Interior Gateway Protocol) protokollide perekonda kuuluva protokolli abil (nt OSPF) ASi sees ning ASide vahel EGP (Exterior Gateway Protocol) perekonna protokollidega (reeglina BGP4 protokolliga). Reeglina kasutab AS ühte või enamat nö mõistliku suurusega aadressruumi osa. Näiteks aadressil http://www.radb.net/ asub Routing Assets Database, mille abil saab küsida, millisele organisatsioonile usaldatud aadressruumi kuulub mingi konkreetne ip aadress.
OSPF (Open Shortest Path First) protokoll on IGP protokollide perekonda kuuluv ruutinguprotokoll. Käesolevas tekstis esitatud kasutusjuhtum on suhteliselt erandlik, kuid igati väärikas ja praktiline juhtum, mis sobib ruutinguprotokolliga tutvuse tegemiseks, kusjuures piisab kui on kasutada nö tavaline PC arvuti.
OpenOSPFD on porditud ka FreeBSD'le, asub see portsude all net/openospfd harus. Allolev konfiguatsioon peaks samuti olema pea täielikult FreeBSD ühilduv. Meeles tuleb ainult pidada, et konfiguratsioonifailid asuvad /usr/local/etc.
Akronüümid
- LSA - link-state advertisements
- FIB - Forwarding Information Base
- RIB - Routing Information Base
- DR, BDR - Designated Router, Backup Designated Router
Kahe võrgusõlme omavahel ühendamine kasutades dubleeritud ühendusi
Olgu eesmärgiks kahe lokatsiooni vahel moodustada kahe füüsilise lingi abil redundantne ühendus
- igal ajahetkel käib andmevahetus üle ühe või teise lingi
- kui üks link rikneb, arvutavad ruuterid automaatselt ruutingutabelid ümber ja andmevahetus jätkub üle teise lingi
Kusjuures antud juhtumi katsetus on viidud läbi VMware Server v. 2 platvormil töötavate virtuaalsete arvutitega.
___ | | ___ | |------ 192.168.15.253 192.168.15.254 ------| | |___| | ____ em1 em1 ____ | |___| | | |------ 1 Gbit/s -----| | | 192.168.17.17 --------| | | |--------- 192.168.14.14 ___ | em0 | | | | em0 | ___ | |------ |____|------ 10 Mbit/s -----|____| ------| | |___| | em2 em2 | |___| | 192.168.16.253 192.168.16.254 | | | Harukontor Peakontor
Sarnast tulemuse saab üldiselt saavutada kahel moel
- redundantsus moodustatakse etherneti kihis - võrguseadmete nn trunking; tavaliselt on sellisel juhtumil füüsiline otspunktide kaugus piiratud nö kaabli pikkusega, kuni mõned sajad meetrid
- redundantsus moodustatakse ip kihis - kasutatakse ruutinguprotokolle, nagu nt antud juhtumil ospf; iseenesest ei ole otspunktide vahekaugus praktiliselt piiratud
Enne OpenOSPFD tarkvara seadistamist tuleb ruuterite võrguseadmed seadistada. Seejärel moodustada kummaski arvutis sellise sisuga /etc/ospfd.conf seadistusfailid.
Ruuteri seadistamine harukontoris
/etc/ospfd.conf sisu võiks olla nt selline
router-id 0.0.0.2 redistribute connected # areas area 0.0.0.0 { interface em1 { metric 100 } interface em2 { metric 10 } }
Ruuteri seadistamine peakontoris
/etc/ospfd.conf sisu võiks olla nt selline
router-id 0.0.0.1 redistribute connected # areas area 0.0.0.0 { interface em1 { metric 100 } interface em2 { metric 10 } }
OpenSPFD käivitamine
OpenSPFD käivitamiseks nn foregroundis ja verbaalses režiimis sobib öelda kummaski ruuteris
# ospfd -dv
Tavalise st deemonina käivitamiseks käsurealt jätta võtmed ära
# ospfd
Selleks, et OpenSPFD käivituks arvuti alglaadimisel peab /etc/rc.conf.local failis sisalduma rida
ospfd_flags=""
Haldamine
OpenOSPFD haldamine toimub utiliidiga ospfctl, nt sedasi saab küsida ruuteri seadmeid
# ospfctl show int Interface Address State HelloTimer Linkstate Uptime nc ac em2 192.168.16.254/24 DR 00:00:08 active 00:00:06 1 1 em1 192.168.15.254/24 DR 00:00:08 active 13:27:30 1 1
Tulemuse kontroll
Püstitatud eesmärgi täitmise kontrollimiseks sobib peab saama katkestada ühe kanali ja ühendus peab jääma tööle; ning peale katkestatud kanali tagasiühendamist (ning andes minutike aega ruutingute stabiliseerumiseks) katkestades teise kanali peab ühendus jällegi jääma otspunktide vahel käima. Ühe kanali katkestuse korral võiks paista selline naabrus
# ospfctl show nei ID Pri State DeadTime Address Iface Uptime 0.0.0.1 1 FULL/BCKUP 00:00:39 192.168.16.253 em2 00:01:31 0.0.0.1 1 DOWN/DOWN 00:00:09 192.168.15.253 em1 -
Võrgu ühendamine teenusepakkujaga kahe ühenduspunkti kaudu
Eesmärgiks on teenuseid pakkuv võrgusegment ühendada ühe ja sama teenusepakkuja võrguga kahe punkti kaudu, kusjuures ühenduspunktides kasutatakse erinevaid ip aadresse.
_____ | | smtp client |_____| | 172.3.1.31 | -> 172.16.0.13:25 ------------|----------|-- | internet | __|__ em2 172.31.1.254 | | 10.0.21.190/24 em0 | R5 | em1 10.0.22.190/24 ,------------------|_____|-------------------, | | 10.0.21.254/24 em1 __|__ __|__ em1 10.0.22.254/24 | | | | | R1 | ISP | R2 | |_____| |_____| 192.168.111.161/29 em0 | | em0 192.168.111.113/29 | | | | | | 192.168.111.162/29 em0 __|__ TEENUSED __|__ em0 192.168.111.114/29 (172.16.0.13:25 -> | | | | (172.16.0.13:25 -> 10.0.13.13:25) | R3 | em2 10.0.222.1 10.0.222.2 em2 | R4 | 10.0.13.13:25) |_____|--------------------------------------|_____| 10.0.13.11/24 em1 | | em3 172.16.0.11/24 172.16.0.12/24 em3 | | em1 10.0.13.12/24 | | | | | | | | | | carp16 172.16.0.1/24 | | | '------------------------------------------' | | | | | | | | carp13 10.0.13.1/24 | --------|--|----------------------------------------------|------------ | subnet of serveris __|__ 10.0.13.13/24 | | |_____| stmp server
kus
- R5 - teenusepakkuja nö sisemine ruuter ja selle taha jääb avalik internet
- R1, R2 - kõnealuste ühenduspunktide teenusepakkuja poolsed ruuterid
- R2, R4 - vastavad teenuseid pakkuva võrgusegmendi poolsed ruuterid
- 192.168.111.160/29 ja 192.168.111.112/29 avalike aadressidega võrke kasutatakse ainult ruutimiseks, nende võrkude ip aadressid ei ole pakutavate teenustega seotud
- teenuseid pakutakse seoses 172.16.0.0/24 võrgu avalike aadressidega, NAT teisenduste abil jõuab liiklus privaatse aadressiga serverini
- teenust pakkuvad serverid kasutavad privaatseid 10.0.13.0/24 võrgu aadresse
- võrgusegmendi arvutite vaikelüüsi aadress 10.0.13.1 on seostatud carp13 võrguseadmega, mida saavad tulemüürid käest kätte anda
- teenusega seotud avalikule ip aadressile saadatud liiklus saadetakse edasi privaatse aadressiga serverile kasutades tulemüürides aadressteisendusi
- üle tulemüüride em2 seadmete käiva otseühenduse käib pfsync liiklus
- CARP seade on seadistatud selliselt
R3 # cat /etc/hostname.carp13 inet 10.0.13.1 255.255.255.0 10.0.13.255 advskew 80 vhid 13 carpdev em1 pass password13
R4 # cat /etc/hostname.carp13 inet 10.0.13.1 255.255.255.0 10.0.13.255 advskew 120 vhid 13 carpdev em1 pass password13
- teenustega seotud avalike aadresside võrgust on seadistatud tulemüüris nö fiktiivne carp seade (üle füüsiliselt töötava võrgu, et carp failover tegelikult ka toimiks)
R3 # cat /etc/hostname.carp16 inet 172.16.0.1 255.255.255.0 172.16.0.255 advskew 80 vhid 16 carpdev em3 pass password16
R4 # cat /etc/hostname.carp16 inet 172.16.0.1 255.255.255.0 172.16.0.255 advskew 120 vhid 16 carpdev em3 pass password16
Kõigis ruuterites on kasutusel OpenBSD operatsioonisüsteem ning OpenOSPFD ruutingutarkvara, kasutatud on selliseid /etc/ospfd.conf seadistusfaile
- R5:
router-id 172.31.1.254 redistribute connected redistribute default # areas area 0.0.0.0 { interface em0 { metric 10 } interface em1 { metric 20 } }
- R1:
router-id 192.168.111.161 redistribute connected redistribute default # areas area 0.0.0.0 { interface em0 { metric 10 } interface em1 { metric 10 } }
- R2
router-id 192.168.111.113 redistribute connected redistribute default # areas area 0.0.0.0 { interface em0 { metric 20 } interface em1 { metric 20 } }
- R3
router-id 192.168.111.162 redistribute 172.16.0.0/24 set { metric 10 } # areas area 0.0.0.0 { interface em0 { metric 10 } interface em2 { metric 30 } interface carp16 demote carp 50 }
- R4
router-id 192.168.111.114 redistribute 172.16.0.0/24 set { metric 20 } # areas area 0.0.0.0 { interface em0 { metric 20 } interface em2 { metric 30 } interface carp16 demote carp 50 }
kusjuures redistribute parameetri kohta kehtivad sellised tähelepanekud
- redistribute vaikeväärtus (st kui parameetrit pole seadistusfailis üldse kasutatud) - jagatakse area kirjelduses kasutatud interface'dega seotud võrkude ruutinguid
- redistribute connected - jagatakse välja kõige võrguseadmetega seotud ruutinguid
- redistribute 172.16.0.0/24 - jagatakse välja 10.0.11.0/24 staatiliselt ruutingutabelisse seadistatud võrku
- no redistribute 10.0.13.0/24 - ei jagata 10.0.13.0/24 võrku
- redistibute default - antakse ümbruse töötavatele ospf deemonitele teada, et nad kasutaksid kõnealust arvutit vaikelüüsina (vastavalt seda seadet, mis kõnealusest arvutist nende poole jääb)
- demote carp 50 - kui ükski ospf naaber ei ole aktiivne, siis suurendatakse carp'i demote väärtust 50 võrra, st praktiliselt toimub carp failover
Redistribute abil ei saa jagada välja ruutingut, mida ei ole kõnealuses arvutis olemas (kas siis seoses mõne seadmega või staatiliselt seadistatune).
Nt olgu arvuti ühendatud nelja võrgukaardiga sellistesse võrkudesse
- em0 - 192.168.10.0/24
- em1 - 10.0.11.0/24
- em2 - 10.0.12.0/24
- em3 - 10.0.13.0/24
siis seadistusfail
no redistribute 192.168.10.0/24 redistribute connected # areas area 0.0.0.0 { interface em1 { metric 10 } interface em2 { metric 20 } }
korraldab, et
- ei jagata välja 192.168.10.0/24 võrgu ruutingut
- jagatakse välja kõigi võrkude ruutinguid mis on arvutiga ühendatud
- ruutinguid jagatakse edasi üle em1 ja em2 võrkude (st suheldes sinna ühendatud muude ospf deemonitega)
OSPF ja CARP
OSPF ja CARP koos kasutamisel tuleb tähele panna, et
- ruuter saadab OSPF liiklust välja ainult siis, kui CARP seade on master olekus; kusjuures sellel CARP seadmel peab olema aadress sellest võrgust, mille ruutimist OSPF abil juhitakse, sel põhjusel on em3 seadmed seadistatud nö fiktiivse tähendusega 172.16.0.0/24 võrku.
- kuigi ainult carp master tekitab ospf liiklust on kasutatud vasakul ja paremal pool erinevaid metric väärtusi
- kui parasjagu aktiivse tulemüüri (R4) välisel ühendusel juhtub midagi OSPFiga (nt öelda R4 tulemüüril ifconfig em0 down), siis OSPF lülitab liikluse ümber R3 peale, kuid CARP seadme masterit automaatselt ümber ei paigutata. Antud juhul on kasutatud kahe tulemüüri vahel otseühendust (R3 ja R4 ruuterite em2 seadmete vahel) ning seejuures leiab aset asümmeetriline ruuting, st teenuse serverist väljuvad paketid mööda teed
server -> R4 -> R3 -> R1 -> R5 -> internet
ja teenuse serverisse saabuvad paketid
internet -> R5 -> R1 -> R3 -> server
Alternatiiviks otseühendusele kahe ruuteri vahel oleks kasutada programmi ifstated võimalusi carp masteri lülitamiseks.
OSPF ja PF
Paketifiltri kasutamine sellise OSPF lahendusega tulemüüride juures osutub mõne sobiva asjaolu tõttu praktiliselt lihtsamaks kui võiks esmapilgul eeldada. Allpool on esitatud kogu skeemist ainult tulemüüride ja server
192.168.111.162/29 em0 __|__ TEENUSED __|__ em0 192.168.111.114/28 | | | | | R3 | 10.0.222.2 em2 | R4 | |_____|----------------------|_____| 10.0.13.11/24 em1 | em2 10.0.222.1 | em1 10.0.13.12/24 | | | | | carp13 10.0.13.1/24 | --------|---|----------------------------|------------ | subnet of serveris __|__ 10.0.13.13/24 | | (192.168.110.13:25 -> 10.0.13.13:25) |_____| stmp server
Nt võiks sobida kasutada kummaski tulemüüris sellist paketifiltri äärmiselt lubavat reeglistikku
# MACROS tcpopts="flags S/SA modulate state" synopts="flags S/SAFR synproxy state" udpopts="keep state" icmp_types="echoreq" if_ext="em1" if_int="em2" if_direct="em3" # OPTIONS set state-defaults pflow set limit states 20000 set limit src-nodes 15000 set block-policy drop set loginterface $if_ext set skip on lo0 # FILTERS block in log on $if_ext label "ESext vaikimisi" block out log on $if_ext label "EVext vaikimisi" block in log on $if_int label "ESint vaikimisi" block out log on $if_int label "EVint vaikimisi" block in log on $if_direct label "ESdirect vaikimisi" block out log on $if_direct label "EVdirect vaikimisi" # carp, ospf ja pfsync liiklus pass quick on $if_int proto carp pass quick on $if_ext proto ospf pass quick on $if_direct proto ospf pass quick on $if_direct proto pfsync # lubada siltidega kogu ipv4 liiklust pass in quick on $if_int inet tag TO_EXT pass out quick on $if_ext tagged TO_EXT pass in quick on $if_ext inet tag TO_INT pass out quick on $if_int tagged TO_INT
ning sellise seadistusega pfsync0 seadmeid
R3 # cat /etc/hostname.pfsync0 up syncdev em3 syncpeer 10.0.222.2 R4 # cat /etc/hostname.pfsync0 up syncdev em3 syncpeer 10.0.222.1
Kui tekib eelmises ospf + carp punktis kirjeldatud asümmeetriline liiklus, siis ka see läbib paketifiltri, isegi vaatamata asjaolule, et ilmutatult ei ole üle em3 võrguseadme lubatud muud peale ospf ja pfsync liikluse. Andmevahetus toimub järgmistel põhjustel
- paketifiltri olekuid sünkroniseeritakse kahe tulemüüri vahel (tundub, et master -> slave ja slave -> master)
- vaikimisi kontrollitakse olekuid nö state-policy = floating tingimustes, mis tähendab muuhulgas, et paketifilter kontrollib vastuspakette vaatamata, milliselt võrguseadmelt need sisenevad, kusjuures antud juhul sisenevad nad isegi teisest arvutist
Selleks, et saaks serverist pöörduda interneti suunas asümmeetrilise ruutingu tingimustes tuleks lisada veel üks reegel, st nö EXT siltidega sektsioon oleks siis selline
pass in quick on $if_int inet tag TO_EXT pass out quick on $if_ext tagged TO_EXT pass out quick on $if_direct tagged TO_EXT
Peab siiski märkima, et asümmeetrilisel juhul on liiklus just ühenduste tekkimisel pisikese viivitusega, tõenäoliselt seetõttu, et olekud peavad kahe tulemüüri vahel propageeruma nö reaalajas.
ospfctl utiliidi kasutamine
- ospfctl show int väljund näitab ruuteri omadusi erinevate seadmetega seotud võrkudes, nt kas ta on DR ja BCKUP andmebaasiks neindes ehternetides. Nt ühe subneti ühes osalises öeldes
yks # ospfctl show int Interface Address State HelloTimer Linkstate Uptime nc ac ... em3 10.0.222.2/24 BCKUP 00:00:01 active 02:04:30 1 1 em1 192.168.111.114/29 DR 00:00:01 active 02:04:30 1 1
ja teises
teine # ospfctl show int Interface Address State HelloTimer Linkstate Uptime nc ac .. em3 10.0.222.1/24 DR 00:00:04 active 01:49:37 1 1 em1 192.168.111.162/29 DR 00:00:02 active 01:49:37 1 1
kust on näha, et üks ruuter on 10.0.222.0/24 võrgus DR ja teine tema BCKUP.
- ospfctl show nei väljund näitab ruuteri naabrite omadusi erinevate seadmetega seotud võrkudes. Nt eelmise punkti 'yks' (id 192.168.111.114) ruuteri kohta tema 192.168.111.162/29 võrgu suhtes võiks öelda tolles võrgus olev naaber nii
naaber # ospfctl show nei ID Pri State DeadTime Address Iface Uptime .. 192.168.111.114 1 FULL/DR 00:00:30 192.168.111.114 em1 01:42:46
ning tema 10.0.222.2/24 võrgus oleva rolli kohta võiks vastava võrgu naaber öelda nii
# ospfctl show nei ID Pri State DeadTime Address Iface Uptime .. 192.168.111.114 1 FULL/BCKUP 00:00:31 10.0.222.2 em3 02:11:17
St ruuteri arvamus enda DR või BCKUP oleku kohta kapib naaberite arvmausega, FULL tähistab asjaolu, et ruutingute andmebaas on täielik.
Märkused
- Kui sama võrk on näha mõnes ruuteris sama metric väärtusega, nt
# ospfctl show rib Destination Nexthop Path Type Type Cost Uptime 192.168.110.128/25 10.0.22.254 Type 1 ext Network 30 00:03:01 192.168.110.128/25 10.0.21.254 Type 1 ext Network 30 00:02:56
siis on ruutingutabelis kaks sissekannet.
- OSPF liiklus paistab võrgus selline, st pakette saadetakse multicast mac ja ip aadressidele
# tcpdump -nei em1 proto ospf 22:30:23.867538 00:0c:29:e7:4c:4e 01:00:5e:00:00:05 0800 82: 192.168.111.161 > 224.0.0.5: \ OSPFv2-hello 48: backbone dr 192.168.111.162 bdr 192.168.111.161 [tos 0xc0] [ttl 1] 22:30:23.867641 00:0c:29:ec:33:48 01:00:5e:00:00:05 0800 82: 192.168.111.162 > 224.0.0.5: \ OSPFv2-hello 48: backbone dr 192.168.111.162 bdr 192.168.111.161 [tos 0xc0] [ttl 1]
- OSPF liiklust saab lubada nt sellise paketifiltri reegliga
pass quick on $if_ext proto ospf