Egymásba ágyazott ismétlődések kezelése TShark field print opciókkal

Tegyük fel, hogy szkriptet kell írnunk, ami valamiféle statisztikát készít mondjuk IPIP vagy GRE tunnelezett forgalomról. Mintának egyből használhatjuk a packetlife.net-ről a GRE.cap-ot. A tunnel ebben az esetben a 10.0.0.1 és a 10.0.0.2 közt van kihúzva, a tunnelen belül pedig az 1.1.1.1 és a 2.2.2.2 kommunikál egymással:

Ha mindezt CLI-ben szeretnénk feldolgozni, akkor persze TSharkra lesz szükség, és egy kicsit állítgatni kell az alapértelmezett outputon. Egyszerűsítsük le a végletekig a dolgot, csak a forrás, illetve a cél IP-ket jelenítsük meg:

karsair@betazed:~$ tshark -r GRE.cap -T fields -e ip.src -e ip.dst -E separator=\;
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1
1.1.1.1;2.2.2.2
2.2.2.2;1.1.1.1

Nos, ez nem egészen az, amire szükség van, hiszen itt csak a GRE payload IP-k látszanak, azaz az ip.src és az ip.dst mezők utolsó előfordulásai minden egyes keretben. Ettől többet sajnos nem is várhatunk egészen a Wireshark 1.6-os verziójáig. Az új stabil Wireshark ágban azonban már gondoltak a rekurzivitás barátaira, új opciók vannak ugyanis a hasonló esetek kezelésére. Egyrészt megváltozott az alapértelmezett viselkedés a TShark-ban, -e után megadott mező összes előfordulását kilistázza a program vesszővel elválasztva:

karsair@betazed:~$ /opt/wireshark-1.6.5/bin/tshark -r GRE.cap -T fields -e ip.src \
-e ip.dst -E separator=\;
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1
10.0.0.1,1.1.1.1;10.0.0.2,2.2.2.2
10.0.0.2,2.2.2.2;10.0.0.1,1.1.1.1

Másrészt vadonatúj field print opcióként itt az "occurrence". Az eddigi field print opciókkal be lehetett állítani, hogy legyen-e az outputban fejléc (-E header=y), a fenti példákban már bemutatott separator opcióval megadhattunk mezőelválasztó karaktert (-E separator=\;), illetve kérhettünk idézőjeleket a mező tartalma köré (pl. -E quote=d). Most viszont azt is megadhatjuk az occurrence opcióval, hogy az adott nevű mező első (f), utolsó (l) vagy összes (a) előfordulását szeretnénk látni, így akár imitálhatjuk az 1.6-os verziók előtti viselkedést (-E occurrence=l):

karsair@betazed:~$ /opt/wireshark-1.6.5/bin/tshark -r GRE.cap -T fields -e ip.src \
-e ip.dst -E separator=\; -E header=y -E quote=d -E occurrence=l
ip.src;ip.dst
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"
"1.1.1.1";"2.2.2.2"
"2.2.2.2";"1.1.1.1"

Ami még ide tartozik, mégis kimaradt az eddigi példákból, az az aggregator field print opció, ami az -e után megadott nevű mező(k)nek az adott keretben való előfordulásait elválasztó karaktert definiálja, az alábbi példában ez a kettőspont:

karsair@betazed:~$ /opt/wireshark-1.6.5/bin/tshark -r GRE.cap -T fields -e ip.src \
-e ip.dst -E separator=\; -E quote=d -E occurrence=a -E aggregator=:
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"
"10.0.0.1:1.1.1.1";"10.0.0.2:2.2.2.2"
"10.0.0.2:2.2.2.2";"10.0.0.1:1.1.1.1"

Eljutottunk tehát odáig, hogy a TShark egy jól konfigurálható kimentet ad a poszt elején vázolt szkript számára, az IP-ket pakolgathatjuk tömbökbe, ide-oda, számolgathatjuk, hogy melyik hányszor fordult elő ilyen külső IP, amolyan belső IP mellett, de az már egy másik történet.

GRE/IPSec tunnel Cisco és Vyatta eszközök közt

Korábban volt már egy hasonló című poszt (GRE tunnel IPSec-ben Cisco és Vyatta eszközök közt), gyanús lehet, hogy most ugyanazt elsütöm mégegyszer, pedig nem, a mostani pár sorban különbözik :). Akkor Adrian F. Dimcev ötletére épülve egy loopback interfészes trükk közbeiktatásával készült kézzel összedrótozgatott GRE/IPSec-hez hasonló megoldás, azonban a Vyatta 6.3 új IPSec VPN lehetőségeinek hála egyszerűbben is megoldható a probléma. A mostani teszt során az alábbi topológia készült el:

A környezet felépítéséhez egy Cisco 3725-ös routert, illetve Vyatta oldalon egy Vyatta Core 6.3-assal telepített mezei PC-t használtam. A Cisco oldali konfiguráció a következőképp alakul:

interface FastEthernet0/0
  ip address 172.17.136.254 255.255.248.0
  no shutdown
  exit

interface FastEthernet0/1
  ip address 10.10.20.1 255.255.255.0
  no shutdown
  exit

crypto isakmp policy 10
  encr aes 256
  hash sha
  authentication pre-share
  lifetime 28800
  group 5
  exit
 
crypto isakmp key TITOK address 172.17.136.255
 
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 10.0.0.2 255.255.255.252
  tunnel source 172.17.136.254
  tunnel destination 172.17.136.255
  tunnel protection ipsec profile TESZTPROFIL
exit

ip route 10.10.10.0 255.255.255.0 10.0.0.1

GRE/IPSec esetén crypto map-et, crypto ACL-t, nem kell megadnunk (milyen subnetből milyen subnetbe megy az IPSec-kel védett forgalom), hiszen az a GRE tunnelben fog utazni, az IPSec-nek pedig itt csak annyit kell tudnia, hogy mi a két IP a GRE tunnel két végén, és hogy e két IP között a GRE forgalom legyen titkosítva. A minimalista tesztkonfigot a GRE szomszédra mutató, a túloldali védett subnethez tartozó route zárja. A Vyatta konfiguráció sem bonyolultabb, sőt szerintem áttekinthetőbb, jobban csoportosított, pirossal emeltem ki a Vyatta 6.3-ban bemutatkozó új lehetőséget (az IPSec processz által lekezelendő forgalom megadása protokollal):

set interfaces ethernet eth0 address 172.17.136.255/21
set interfaces ethernet eth1 address 10.10.10.1/24
 
set interfaces tunnel tun1 address 10.0.0.1/30
set interfaces tunnel tun1 encapsulation gre
set interfaces tunnel tun1 local-ip 172.17.136.255
set interfaces tunnel tun1 remote-ip 172.17.136.254

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 lifetime 3600

set vpn ipsec ipsec-interfaces interface eth0

set vpn ipsec site-to-site peer 172.17.136.254
set vpn ipsec site-to-site peer 172.17.136.254 authentication mode pre-shared-secret
set vpn ipsec site-to-site peer 172.17.136.254 authentication pre-shared-secret TITOK
set vpn ipsec site-to-site peer 172.17.136.254 ike-group TESZT-IKE-GROUP
set vpn ipsec site-to-site peer 172.17.136.254 local-ip 172.17.136.255
set vpn ipsec site-to-site peer 172.17.136.254 tunnel 1
set vpn ipsec site-to-site peer 172.17.136.254 tunnel 1 esp-group TESZT-ESP-GROUP
set vpn ipsec site-to-site peer 172.17.136.254 tunnel 1 protocol gre

set protocols static route 10.10.20.0/24 next-hop 10.0.0.2

A végeredmény a korábban bemutatott megoldáshoz képest egyszerűbb, a két eszköz mögötti védett hálózatok forgalma azonban a korábbiakhoz hasonlóan IPSec tunnelben, azon belül GRE tunnelben utazik az egyik routertől a másikig. A megoldás tesztelését könnyen megejthetjük mondjuk egy telnet sessionnel pl. a 10.10.10.2-es hostról a 10.10.20.2-es hostra, nyilvánvalóan ezeket a hostokat is fel kell konfigurálni (IP cím, default route, telnet szolgáltatás). Ha a már működő telnet sessionbe belehallgatunk a megfelelő Vyatta interfészen tsharkkal, akkor viszont csak az ESP payloadot láthatjuk, várakozásainknak megfelelően:

vyatta@vyatta:~$ sudo tshark -i eth0 
Running as user "root" and group "root". This could be dangerous.
Capturing on eth0
  0.000000 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.018434 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  0.018748 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.179962 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.198421 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  0.198757 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.319907 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.338476 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  0.338800 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.459966 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.478455 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  0.478774 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.879923 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  0.898456 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  0.898779 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.027966 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.048497 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  1.048816 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.067968 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.088483 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  1.126881 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.239920 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.258538 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  1.258873 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.379974 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.398574 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  1.398900 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.759984 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)
  1.778730 172.17.136.254 -> 172.17.136.255 ESP ESP (SPI=0xdf68cfb5)
  1.779053 172.17.136.255 -> 172.17.136.254 ESP ESP (SPI=0x745a7e79)

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):

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-Cisco

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

Konfiguráció az R2-Vyatta eszközön:

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