Elképesztő, hogy micsoda könnyedséggel tud beszélni Radia Perlman mindenféle hálózati protokollokról, és hogy mennyire meg tudja ragadni a lényeget egy-egy szinte ovis szinten felvázolt ábrával. Bájos az is, hogy nem hagyja magát zavartatni csip-csup részletekkel (pl. a TRILL részleteinek tágyalásánál a per-ingress tree melleti érvelés a 36-37. percnél). Szóval szinte tátott szájjal néztem végig a TRILL protokollról (Transparent Interconnection of Lots of Links) szóló előadásáról készült videót, amelyben felvázolja az általa gyakorlatilag egyetlen este kitalált STP protokollhoz vezető lépéseket (hatalmas a sztori az első bridge-ről, amibe beletették az STP-t, kb. 15:30-tól), illetve részletesen beszél a felvétel készítése óta (2008) nem túl nagy karriert befutott TRILL-ről.
2011-02-11
GRE tunnel IPSec-ben Cisco és Vyatta eszközök közt
A nem azonos gyártótól származó eszközök közötti korábbi egyszerű IPSec tunneles posztok után gondoltam, kipróbálom az IPSec-be ágyazott GRE tunnelt Cisco és Vyatta eszközök közt. Bár a GRE alapvetően Cisco technológia, más gyártók is támogatják használatát, többek közt a Vyatta rendszerek is.
A GRE/IP tunnelek nagy előnye az egyszerű IPSec tunnelekhez képest, hogy külön virtuális tunnel interfészünk van, ami az unicast IP forgalmon kívül (amit az egyszerű IPSec tunnel is tud) ismeri a multicastot és a broadcastot is, így akár egy olyan irányító protokoll is működhet GRE-n keresztül, mint az OSPF. Ugyanakkor a GRE/IP semmilyen biztonságot nem nyújt, nem titkosított a payload benne, ezért is gondolták a Cisco-nál, hogy jó ötlet lesz az IPSec-kel házasítani, így született meg a GRE/IPSec, amit egy Cisco routeren körülbelül így kell konfigurálni (az IPSec beállítások megegyeznek a korábbi táblázatban leírtakkal):
Látható, hogy nincs szükség GRE/IPSec esetén crypto map-re, tehát crypto ACL-re sem (amivel egyébként egy kis figyelmetlenséggel pillanatok alatt ki tudjuk zárni magunkat a távoli routeről), így nem kell megadnunk azt sem, hogy milyen subnetből milyen subnetbe megy az IPSec-kel védett forgalom, hiszen az a GRE tunnelben fog utazni, az IPSec fölött, így az IPSec-nek elég azt tudnia, hogy mi a két IP a GRE tunnel két végén (tunnel source, tunnel destination), e két IP közt pedig elég a GRE forgalmat titkosítani, minden más már a GRE-n belül fog utazni. Na, ez az, amit nem lehet összehozni Vyatta alatt, legalábbis most (VC-6.1) még nem, de talán már a következő kiadásban benne lesz.
Megjegyzés (2011-08-26): a Vyatta 6.3-as verziójától kezdve elérhető a kérdéses lehetőség, amit egy külön posztban meg is vizsgáltam.
Létezik azonban más megközelítés is: ha közbeiktatunk egy loopback interfészt, és mi magunk drótozgatunk össze egy GRE/IPSec-like megoldást. A lényeg változatlan marad, a GRE alatt IPSec lesz, viszont ezt a Vyatta is támogatja. Az ötlet alapvetően annyi, hogy a GRE tunnelt fizikai interfészek helyett loopback interfészek IP-i közt húzzuk ki, és ezeket a loopback IP-ket engedjük át az IPSec tunnelen, az IPSec pedig ugye már a rendes külső IP-nken fog átmenni a peerhez. A túloldalon ugyanúgy él a két router közti IP kapcsolat, ott is rátesszük az IPSec-et, abba is beletesszük a loopbackek közti GRE-t, amibe végül önthetjük mindazt, amit meg ezen az oldalon szeretnénk látni. Konfiguráció szempontjából persze kényelmetlenebb ez a fenti megoldásnál mind a Cisco mind a Vyatta oldalán, de a végén lehet egy olyan GRE tunnelünk IPSec felett, amelyben szépen dolgozgat az OSPF, és bármilyen egyéb hálózatot átrouteolhatunk rajta, függetlenül attól, hogy mi van beállítva a crypto ACL-ben. Simán megéri. A tesztkörnyezet topológiája a következő:
Konfiguráció az R1-Cisco eszközön:
A GRE/IP tunnelek nagy előnye az egyszerű IPSec tunnelekhez képest, hogy külön virtuális tunnel interfészünk van, ami az unicast IP forgalmon kívül (amit az egyszerű IPSec tunnel is tud) ismeri a multicastot és a broadcastot is, így akár egy olyan irányító protokoll is működhet GRE-n keresztül, mint az OSPF. Ugyanakkor a GRE/IP semmilyen biztonságot nem nyújt, nem titkosított a payload benne, ezért is gondolták a Cisco-nál, hogy jó ötlet lesz az IPSec-kel házasítani, így született meg a GRE/IPSec, amit egy Cisco routeren körülbelül így kell konfigurálni (az IPSec beállítások megegyeznek a korábbi táblázatban leírtakkal):
crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 5
exit
crypto isakmp key TITOK address <peer IP>
crypto ipsec transform-set TESZTSET esp-aes 128 esp-md5-hmac
exit
crypto ipsec security-association lifetime seconds 3600
crypto ipsec profile TESZTPROFIL
set transform-set TESZTSET
exit
interface Tunnel 0
ip address <tunnel IP-je> <netmask>
tunnel source <saját külső IP>
tunnel destination <peer IP>
tunnel protection ipsec profile TESZTPROFIL
exit
Látható, hogy nincs szükség GRE/IPSec esetén crypto map-re, tehát crypto ACL-re sem (amivel egyébként egy kis figyelmetlenséggel pillanatok alatt ki tudjuk zárni magunkat a távoli routeről), így nem kell megadnunk azt sem, hogy milyen subnetből milyen subnetbe megy az IPSec-kel védett forgalom, hiszen az a GRE tunnelben fog utazni, az IPSec fölött, így az IPSec-nek elég azt tudnia, hogy mi a két IP a GRE tunnel két végén (tunnel source, tunnel destination), e két IP közt pedig elég a GRE forgalmat titkosítani, minden más már a GRE-n belül fog utazni. Na, ez az, amit nem lehet összehozni Vyatta alatt, legalábbis most (VC-6.1) még nem, de talán már a következő kiadásban benne lesz.
Megjegyzés (2011-08-26): a Vyatta 6.3-as verziójától kezdve elérhető a kérdéses lehetőség, amit egy külön posztban meg is vizsgáltam.
Létezik azonban más megközelítés is: ha közbeiktatunk egy loopback interfészt, és mi magunk drótozgatunk össze egy GRE/IPSec-like megoldást. A lényeg változatlan marad, a GRE alatt IPSec lesz, viszont ezt a Vyatta is támogatja. Az ötlet alapvetően annyi, hogy a GRE tunnelt fizikai interfészek helyett loopback interfészek IP-i közt húzzuk ki, és ezeket a loopback IP-ket engedjük át az IPSec tunnelen, az IPSec pedig ugye már a rendes külső IP-nken fog átmenni a peerhez. A túloldalon ugyanúgy él a két router közti IP kapcsolat, ott is rátesszük az IPSec-et, abba is beletesszük a loopbackek közti GRE-t, amibe végül önthetjük mindazt, amit meg ezen az oldalon szeretnénk látni. Konfiguráció szempontjából persze kényelmetlenebb ez a fenti megoldásnál mind a Cisco mind a Vyatta oldalán, de a végén lehet egy olyan GRE tunnelünk IPSec felett, amelyben szépen dolgozgat az OSPF, és bármilyen egyéb hálózatot átrouteolhatunk rajta, függetlenül attól, hogy mi van beállítva a crypto ACL-ben. Simán megéri. A tesztkörnyezet topológiája a következő:
Konfiguráció az R1-Cisco eszközön:
hostname R1-CiscoKonfiguráció az R2-Vyatta eszközön:
interface Loopback1
ip address 10.10.127.1 255.255.255.255
exit
interface Tunnel1
ip address 10.10.47.1 255.255.255.252
tunnel source 10.10.127.1
tunnel destination 10.10.127.2
exit
interface FastEthernet0/1
ip address 10.1.1.1 255.255.255.0
duplex auto
speed auto
exit
crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 5
lifetime 28800
exit
crypto isakmp key TITOK address 192.168.12.2
crypto ipsec transform-set TESZTSET esp-aes esp-md5-hmac
exit
access-list 100 permit ip host 10.10.127.1 host 10.10.127.2
crypto map TESZTMAP 10 ipsec-isakmp
set peer 192.168.12.2
set transform-set TESZTSET
set pfs group5
match address 100
interface FastEthernet0/0
ip address 192.168.11.2 255.255.255.252
crypto map TESZTMAP
exit
router ospf 1
network 10.1.1.0 0.0.0.255 area 0
network 10.10.47.0 0.0.0.3 area 0
exit
ip route 0.0.0.0 0.0.0.0 192.168.11.1
set system host-name R2-Vyatta
set interfaces ethernet eth0 address 192.168.12.2/24
set interfaces ethernet eth1 address 10.2.2.1/24
set interfaces loopback lo address 10.10.127.2/32
set interfaces tunnel tun1 address 10.10.47.2/30
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 local-ip 10.10.127.2
set interfaces tunnel tun1 remote-ip 10.10.127.1
set vpn ipsec ike-group TESZT-IKE-GROUP
set vpn ipsec ike-group TESZT-IKE-GROUP lifetime 28800
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 dh-group 5
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 encryption aes256
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 hash sha1
set vpn ipsec esp-group TESZT-ESP-GROUP
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 encryption aes128
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 hash md5
set vpn ipsec esp-group TESZT-ESP-GROUP pfs enable
set vpn ipsec esp-group TESZT-ESP-GROUP lifetime 3600
set vpn ipsec site-to-site peer 192.168.11.2
set vpn ipsec site-to-site peer 192.168.11.2 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 192.168.11.2 authentication pre-shared-secret TITOK
set vpn ipsec site-to-site peer 192.168.11.2 ike-group TESZT-IKE-GROUP
set vpn ipsec site-to-site peer 192.168.11.2 local-ip 192.168.12.2
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1 local-subnet 10.10.127.2/32
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1 remote-subnet 10.10.127.1/32
set vpn ipsec site-to-site peer 192.168.11.2 tunnel 1 esp-group TESZT-ESP-GROUP
set system gateway-address 192.168.12.1
set protocols ospf area 0 network 10.10.47.0/30
set protocols ospf area 0 network 10.2.2.0/24
2011-02-05
IPSec site-to-site VPN Cisco és Fortigate eszközökkel
A korábbi Cisco-Cisco majd Cisco-Vyatta felállás után jöjjön most ismét ugyanaz, ám Cisco-Fortinet variációban. A teszteszköz egy Fortigate 60-as, még a régebbi, 3-as FortiOS-szel, de ugyanezek a CLI parancsok használhatók a legfrissebb 4-es verziójú FortiOS-ekben is. A korábbi topológia változatlan:
Az IPSec beállításokat összegző táblázat szintén változatlan, a Cisco-Cisco posztban megtalálható. A vyattás felállással ellentétben a FortiOS parancsokat nem próbálom megfeleltetni az IOS-es parancsoknak, alapvető szemléletbeli különbségek vannak a Fortigate tűzfalak és a Cisco routerek közt, túl sok lenne a különbség, így az IOS-t futtató R1 eszköz beállításai itt nem is szerepelnek, pontról pontra ugyanazt a konfigurációt használtam, amit korábban is.
A korábbi versenyzőkkel ellentétben a Fortigate viszonylag terjedelmes gyári beállításokkal érkezik, NAT/route üzemmódban (ez az alapértelmezett) a következő IP-k vannak a fizikai interfészeken beállítva:
A figyelmesebbeknek szemet szúrhat, hogy történt egy kis csalás ebben a Fortigate beállításban. A korábbiakban sehol sem használtam az IPSec-hez bármilyen módon köthető virtuális interfészt, VTI-t, loopback interfészt, a Cisco routeren és a Vyattán is egyszerű tunnel módban hoztam létre a kapcsolatot, nem hajtottuk át az adatokat semmilyen egyéb interfészen, csak azon, ahol kiléptek a routerből. A Fortigate esetén is elérhető ez a tunnel mód, policy-based VPN-nek hívják, config vpn ipsec phase1-interface helyett a config vpn ipsec phase1 paranccsal kell létrehozni. Phase2-ben szintén a megfelelő parancs interface nélküli változatát kell választanunk, majd egy tűzfalszabályt kell még hozzárendelnünk, ahol ACCEPT vagy DENY helyett az IPSEC műveletet kell a szabályban műveletként megadni (egy tunnelhez csak egy szabály tartozhat). Eddig egyébként még sosem sikerült értelmes módon beállítanom a policy-based VPN-t, például a távoli site-ról kezdeményezett forgalom során nem áll fel magától az IPSec kapcsolat, bármilyen tűzfal policy-vel is próbálkoztam, míg a Fortigate mögötti subnetből meginduló forgalom hatására mindig azonnal létrejött az IPSec összeköttetés.
A másik, a posztban részletesen is bemutatott módszerrel létrehozott, virtuális IPSec interfésszel operáló beállítást a Fortigate rendszerekben route-based VPN-nek nevezik. A virtuális interfész segítségével kezelhetőbbé válnak a IPSec-en keresztül kimenő vagy beérkező csomagok, átláthatóbbak a rájuk vonatkozó tűzfalszabályok, és mivel ekkor önálló interfészként jelenik meg az IPSec tunnel Fortigate-en lévő vége, bármennyi szabály vonatkozhat rá, kedvünk szerint finomhangolhatjuk.
Az IPSec beállításokat összegző táblázat szintén változatlan, a Cisco-Cisco posztban megtalálható. A vyattás felállással ellentétben a FortiOS parancsokat nem próbálom megfeleltetni az IOS-es parancsoknak, alapvető szemléletbeli különbségek vannak a Fortigate tűzfalak és a Cisco routerek közt, túl sok lenne a különbség, így az IOS-t futtató R1 eszköz beállításai itt nem is szerepelnek, pontról pontra ugyanazt a konfigurációt használtam, amit korábban is.
A korábbi versenyzőkkel ellentétben a Fortigate viszonylag terjedelmes gyári beállításokkal érkezik, NAT/route üzemmódban (ez az alapértelmezett) a következő IP-k vannak a fizikai interfészeken beállítva:
- Internal: 192.168.1.99
- WAN1: 192.168.100.99
- WAN2: 192.168.101.99
- DMZ: 10.10.10.1
config system interfaceA következő lépés a Phase1 adatok megadása, minden további beállítás esetén az itt létrehozott néven (TESZT-PH1) tudunk erre a VPN kapcsolatra hivatkozni.
edit "internal"
set ip 10.3.3.1 255.255.255.0
next
edit "dmz"
set status down
next
edit "wan1"
set ip 10.1.1.2 255.255.255.0
next
edit "wan2"
set status down
end
config vpn ipsec phase1-interfaceSzükségünk lesz természetesen Phase2 beállításokra is, amelyek a már létrehozott Phase1 beállításokra fognak épülni:
edit "TESZT-PH1"
set interface "wan1"
set proposal aes256-sha1
set keylife 28800
set remote-gw 10.1.1.1
set psksecret TITOK
end
config vpn ipsec phase2-interfaceEzzel maga az IPSec konfiguráció ugyan készen van, de ne feledjük, hogy a Fortigate-ek alapvetően UTM eszközök, magától szinte semmi sem működik, ha csak nem kreálunk hozzá tűzfalszabályokat. Mielőtt azonban ténylegesen a tűzfal policy-khez nyúlnánk, definiálnunk kell a subneteket, amelyekkel dolgozgatni szeretnénk a későbbiekben:
edit "TESZT-PH2"
set pfs enable
set phase1name "TESZT-PH1"
set proposal aes128-md5
set dst-subnet 10.2.2.0 255.255.255.0
set keylifeseconds 3600
set src-subnet 10.3.3.0 255.255.255.0
end
config firewall addressMiután készen vannak a subnetek, jöhet a tűzfal policy. Ha az alapértelmezett beállításról indulunk, akkor észrevehetjük, hogy egy szabály már létezik a tűzfalon, ami az R2 belső subnet hostjai számára hozzáférést engedélyez a WAN1 interfészen keresztül elérhető dolgokhoz. Ezt a szabályt megtarthatjuk, vagy akár törölhetjük, letilthatjuk (set status disable), attól függően, mire van épp szükségünk, ezért nem eggyel kezdődik a tűzfalszabályok számozása:
edit "R2-belso-subnet"
set associated-interface "internal"
set subnet 10.3.3.0 255.255.255.0
next
edit "R1-belso-subnet"
set associated-interface "TESZT-PH1"
set subnet 10.2.2.0 255.255.255.0
end
config firewall policyA végére maradt a statikus route a távoli subnet felé:
edit 2
set srcintf "internal"
set dstintf "TESZT-PH1"
set srcaddr "R2-belso-subnet"
set dstaddr "R1-belso-subnet"
set action accept
set schedule "always"
set service "ANY"
next
edit 3
set srcintf "TESZT-PH1"
set dstintf "internal"
set srcaddr "R1-belso-subnet"
set dstaddr "R2-belso-subnet"
set action accept
set schedule "always"
set service "ANY"
end
config router staticA FortiOS-ben külön nem szükséges menteni, amint kilépünk az end paranccsal valamilyen objektum konfigurációs módjából, a beállított értékeket a rendszer elmenti, illetve természetesen a futó konfigurációban érvényre juttatja.
edit 1
set device "TESZT-PH1"
set dst 10.2.2.0 255.255.255.0
end
A figyelmesebbeknek szemet szúrhat, hogy történt egy kis csalás ebben a Fortigate beállításban. A korábbiakban sehol sem használtam az IPSec-hez bármilyen módon köthető virtuális interfészt, VTI-t, loopback interfészt, a Cisco routeren és a Vyattán is egyszerű tunnel módban hoztam létre a kapcsolatot, nem hajtottuk át az adatokat semmilyen egyéb interfészen, csak azon, ahol kiléptek a routerből. A Fortigate esetén is elérhető ez a tunnel mód, policy-based VPN-nek hívják, config vpn ipsec phase1-interface helyett a config vpn ipsec phase1 paranccsal kell létrehozni. Phase2-ben szintén a megfelelő parancs interface nélküli változatát kell választanunk, majd egy tűzfalszabályt kell még hozzárendelnünk, ahol ACCEPT vagy DENY helyett az IPSEC műveletet kell a szabályban műveletként megadni (egy tunnelhez csak egy szabály tartozhat). Eddig egyébként még sosem sikerült értelmes módon beállítanom a policy-based VPN-t, például a távoli site-ról kezdeményezett forgalom során nem áll fel magától az IPSec kapcsolat, bármilyen tűzfal policy-vel is próbálkoztam, míg a Fortigate mögötti subnetből meginduló forgalom hatására mindig azonnal létrejött az IPSec összeköttetés.
A másik, a posztban részletesen is bemutatott módszerrel létrehozott, virtuális IPSec interfésszel operáló beállítást a Fortigate rendszerekben route-based VPN-nek nevezik. A virtuális interfész segítségével kezelhetőbbé válnak a IPSec-en keresztül kimenő vagy beérkező csomagok, átláthatóbbak a rájuk vonatkozó tűzfalszabályok, és mivel ekkor önálló interfészként jelenik meg az IPSec tunnel Fortigate-en lévő vége, bármennyi szabály vonatkozhat rá, kedvünk szerint finomhangolhatjuk.
2011-02-01
IPSec site-to-site VPN Cisco és Vyatta VPN routerek közt
A korábbi IPSec site-to-site VPN konfigurációban kicseréltem az R2 routert, és a Cisco eszköz helyett egy Vyatta VC6.1-es OS-szel ellátott x86-os gép került a helyére (lehetett volna akár virtuális gép is). A korábbi topológia változatlan:
A korábbi, IPSec beállításokat összegző táblázat szintén változatlan, nem is másolom be, megtalálható a hivatkozott posztban. Érdekesebb dolog viszont a Cisco IOS és a Vyatta parancsok összevetése, hogy pontosan melyik minek felel meg a másik OS-ben.
Az első lépés az interfészek felkonfigurálása, a Cisco routerben két FastEthernet port van, a Vyattát futtató rendszeren Fa0/0 helyett eth0 lesz az első ethernet interfész Fa0/1 helyett pedig eth1 a másik:
R1 - Cisco IOS
R2 - Vyatta
Mivel egyik oldalon sincs dinamikus routeolás, ezért be kell jegyeznünk a túloldalon lévő subnetet. Ez a lépés a Vyatta rendszeren egyébként elhagyható, ha ugyanis nincs a későbbi IPSec peer beállításoknak megfelelő bejegyzés a route táblában, akkor a tunnel felépülésekor ezt a rendszer automatikusan létrehozza. A teljesség kedvéért azonban itt szerepel az IOS-ben kiadott parancs vyattás megfelelője:
R1 - Cisco IOS
R2 - Vyatta
A következő lépés a 10-es prioritású IKE policy létrehozása IOS-en (természetesen más számot is válaszhatunk 10 helyett). Vyatta esetén ennek nagyjából az IKE group létrehozása felel meg, a példában ez a TESZT-IKE-GROUP nevet viseli:
R1 - Cisco IOS
R2 - Vyatta
A Cisco IOS-ben az isakmp beállítások közt kell megadnunk minden IPSec peerhez a PSK-t, ez a Vyattában csak később, a peer egyéb beállításaival együtt szerepel. Ugyanez érvényes a crypto ACL szabályra, IOS-ben egy extended ACL-t kell létrehoznunk, és azt majd alkalmazni a megfelelő interfészen, ami a Vyattán ugyancsak a peer beállítások közt szerepel:
R1 - Cisco IOS
R2 - Vyatta
A következő sorok a Phase 2-re vonatkoznak, nem feleltethetők meg egymásnak a parancsok egy az egyben, IOS esetén transform set és security assiciation lifetime néven futnak a beállítások, Vyatta esetén pedig ESP group néven, de alapvetően mindkét OS-ben ugyanazt a beállítást végzik el. Vegyük észre azonban, hogy a Vyatta esetén a Perfect Forward Secrecy szintén itt kerül beállításra:
R1 - Cisco IOS
R2 - Vyatta
Következhet a crypto map az IOS-ben, ami nagyjából az ipsec site-to-site peer beállításoknak feleltethető meg Vyatta alatt. Ugye még emlékszünk arra, hogy a Vyattának két dolgot is pótolnia kell, a PSK és a crypto ACL megfelelőit itt fogjuk megadni, míg az IOS a PFS beállításokkal maradt eddig adós:
R1 - Cisco IOS
R2 - Vyatta
Utolsó lépésként a mindkét eszköz külső interfészén engedélyeznünk kell az IPSec-et:
R1 - Cisco IOS
R2 - Vyatta
Jelentős különbség a két rendszer közt, hogy az IOS-ben a parancsok a kiadásuk után azonnal érvényre jutnak, míg a Vyattában addig, amíg ki nem lépünk konfigurációs módból, csak gyűjti a rendszer a változtatásokat, és át tudjuk nézni az összes változást mielőtt érvényesítenénk (commit) őket.
R1 - Cisco IOS
R2 - Vyatta
IPSec hibakereséshez használhatók a következő parancsok:
R1 - Cisco IOS
R2 - Vyatta
A korábbi, IPSec beállításokat összegző táblázat szintén változatlan, nem is másolom be, megtalálható a hivatkozott posztban. Érdekesebb dolog viszont a Cisco IOS és a Vyatta parancsok összevetése, hogy pontosan melyik minek felel meg a másik OS-ben.
Az első lépés az interfészek felkonfigurálása, a Cisco routerben két FastEthernet port van, a Vyattát futtató rendszeren Fa0/0 helyett eth0 lesz az első ethernet interfész Fa0/1 helyett pedig eth1 a másik:
R1 - Cisco IOS
interface FastEthernet0/0
ip address 10.1.1.1 255.255.255.0
no shutdown
exit
interface FastEthernet0/1
ip address 10.2.2.1 255.255.255.0
no shutdown
exit
R2 - Vyatta
set interfaces ethernet eth0 address 10.1.1.2/24
set interfaces ethernet eth1 address 10.3.3.1/24
Mivel egyik oldalon sincs dinamikus routeolás, ezért be kell jegyeznünk a túloldalon lévő subnetet. Ez a lépés a Vyatta rendszeren egyébként elhagyható, ha ugyanis nincs a későbbi IPSec peer beállításoknak megfelelő bejegyzés a route táblában, akkor a tunnel felépülésekor ezt a rendszer automatikusan létrehozza. A teljesség kedvéért azonban itt szerepel az IOS-ben kiadott parancs vyattás megfelelője:
R1 - Cisco IOS
ip route 10.3.3.0 255.255.255.0 10.1.1.2
R2 - Vyatta
set protocols static route 10.2.2.0/24 next-hop 10.1.1.1
A következő lépés a 10-es prioritású IKE policy létrehozása IOS-en (természetesen más számot is válaszhatunk 10 helyett). Vyatta esetén ennek nagyjából az IKE group létrehozása felel meg, a példában ez a TESZT-IKE-GROUP nevet viseli:
R1 - Cisco IOS
crypto isakmp policy 10
encr aes 256
hash sha
authentication pre-share
group 5
lifetime 28800
exit
R2 - Vyatta
set vpn ipsec ike-group TESZT-IKE-GROUP
set vpn ipsec ike-group TESZT-IKE-GROUP lifetime 28800
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 dh-group 5
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 encryption aes256
set vpn ipsec ike-group TESZT-IKE-GROUP proposal 10 hash sha1
A Cisco IOS-ben az isakmp beállítások közt kell megadnunk minden IPSec peerhez a PSK-t, ez a Vyattában csak később, a peer egyéb beállításaival együtt szerepel. Ugyanez érvényes a crypto ACL szabályra, IOS-ben egy extended ACL-t kell létrehoznunk, és azt majd alkalmazni a megfelelő interfészen, ami a Vyattán ugyancsak a peer beállítások közt szerepel:
R1 - Cisco IOS
crypto isakmp key TITOK address 10.1.1.2
access-list 100 permit ip 10.2.2.0 0.0.0.255 10.3.3.0 0.0.0.255
R2 - Vyatta
A peer beállításai közt kell megadni.
A következő sorok a Phase 2-re vonatkoznak, nem feleltethetők meg egymásnak a parancsok egy az egyben, IOS esetén transform set és security assiciation lifetime néven futnak a beállítások, Vyatta esetén pedig ESP group néven, de alapvetően mindkét OS-ben ugyanazt a beállítást végzik el. Vegyük észre azonban, hogy a Vyatta esetén a Perfect Forward Secrecy szintén itt kerül beállításra:
R1 - Cisco IOS
crypto ipsec transform-set TESZTSET esp-aes 128 esp-md5-hmac
crypto ipsec security-association lifetime seconds 3600
R2 - Vyatta
set vpn ipsec esp-group TESZT-ESP-GROUP
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 encryption aes128
set vpn ipsec esp-group TESZT-ESP-GROUP proposal 10 hash md5
set vpn ipsec esp-group TESZT-ESP-GROUP pfs enable
set vpn ipsec esp-group TESZT-ESP-GROUP lifetime 3600
Következhet a crypto map az IOS-ben, ami nagyjából az ipsec site-to-site peer beállításoknak feleltethető meg Vyatta alatt. Ugye még emlékszünk arra, hogy a Vyattának két dolgot is pótolnia kell, a PSK és a crypto ACL megfelelőit itt fogjuk megadni, míg az IOS a PFS beállításokkal maradt eddig adós:
R1 - Cisco IOS
crypto map TESZTMAP 50 ipsec-isakmp
set peer 10.1.1.2
set pfs group5
set transform-set TESZTSET
match address 100
exit
R2 - Vyatta
set vpn ipsec site-to-site peer 10.1.1.1
set vpn ipsec site-to-site peer 10.1.1.1 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 10.1.1.1 authentication pre-shared-secret TITOK
set vpn ipsec site-to-site peer 10.1.1.1 ike-group TESZT-IKE-GROUP
set vpn ipsec site-to-site peer 10.1.1.1 local-ip 10.1.1.2
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0 local-subnet 10.3.3.0/24
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0 remote-subnet 10.2.2.0/24
set vpn ipsec site-to-site peer 10.1.1.1 tunnel 0 esp-group TESZT-ESP-GROUP
Utolsó lépésként a mindkét eszköz külső interfészén engedélyeznünk kell az IPSec-et:
R1 - Cisco IOS
interface FastEthernet0/0
crypto map TESZTMAP
exit
R2 - Vyatta
set vpn ipsec ipsec-interfaces interface eth0
Jelentős különbség a két rendszer közt, hogy az IOS-ben a parancsok a kiadásuk után azonnal érvényre jutnak, míg a Vyattában addig, amíg ki nem lépünk konfigurációs módból, csak gyűjti a rendszer a változtatásokat, és át tudjuk nézni az összes változást mielőtt érvényesítenénk (commit) őket.
R1 - Cisco IOS
end
copy run start
R2 - Vyatta
commit
save
exit
IPSec hibakereséshez használhatók a következő parancsok:
R1 - Cisco IOS
show crypto isakmp sa
show crypto ipsec sa
R2 - Vyatta
show vpn ike sa
show vpn ipsec sa
Feliratkozás:
Bejegyzések (Atom)