A következő címkéjű bejegyzések mutatása: vyatta. Összes bejegyzés megjelenítése
A következő címkéjű bejegyzések mutatása: vyatta. Összes bejegyzés megjelenítése

2012-02-03

Link Layer Discovery protokollok használata (5.) - CDP MikroTiken és Vyattán

Tulajdonképpen egész könnyen meg lehet szokni a MikroTik szoftverplatformját, a RouterOS-t, valójában igazi MikroTik eszköz sem kell ahhoz, hogy kipróbálhassuk, ugyanis van belőle x86-osra fordított változat, így akár virtuális gépre is telepíthető. A legfrissebb, 5.12-es kiadás IPSec-kel, MPLS-sel, NetFlow v9 exporttal, SNMP v3-mal és még számtalan lehetőséggel együtt sem több ~20MB-nál, ami bizony igen kevés, bármilyen mércével mérve, így aztán ideális választásnak tűnik nagyobb virtuális infrastruktúrák hálózati igényeinek kielégítésére.

De nem is erről szólna ez a poszt, hanem a MikroTik és a Vyatta CDP-kompatibilitásáról. A jó hír az, hogy mindkettőn működik, valódi Cisco eszközökkel tesztelve is, szerintem a Mikrotik megoldása a jobb, ugyanis a RouterOS alatt nagyon egyértelműen lehet kezelni a CDP-be bevont interfészeket, míg a Vyattán csak globálisan lehet ki- és bekapcsolni a CDP támogatást, bár állítólag dolgoznak az interfészenkénti ki- és bekapcsoláson. Ugyanakkor a Vyatta ismeri a CDP v2-t is, míg a RouterOS kizárólag CDP v1-et tud. A parancsok részletes leírogatása helyett ezúttal néhány beszédes képernyőképet készítettem, a képekre kattintva nagyobb felbontású változat is elérhető.

A Cisco eszköz látja mindkét CDP-s versenyzőt, a platform információk, a szoftververzió, a kapcsolódó fizikai portok teljesen korrekt módon jelennek meg az IOS-ben:


A MikroTik-es virtuális gép szintén hibátlanul teszi a dolgát, a gyártónál alapértelmezésben minden interfészen aktív a CDP, kivéve a vezeték-nélküli interfészeket, és mintha tunnel interfészeken sem kapcsolná be alapból a CDP-t a RouterOS; a lényeg, hogy vegyük a CDP-t is számításba (elsősorban biztonsági szempontból), amikor MikroTiket teszünk be a hálózatba. A képernyőképen a szomszédok listázása után példa látható arra is, hogyan kapcsolható ki egy adott interfészen a CDP, illetve arra, hogyan listázható az interfészek aktuális CDP-s állapota.


A CDP alapból nem fut a Vyattán, külön be kell kapcsolni (configure > set service lldp legacy-protocols cdp > commit > save). Az IOS CDP kereteitől a rendszer egy kissé megilletődött, kétszer is betette a neighbor táblázatba a Cisco AP-t, egyszer CDP v1-es, egyszer pedig CDP v2-es eszközként, ezt a kis botlást, valamint a többihez képest rendkívüli szószátyárságot leszámítva azonban nagyjából itt is minden rendben van:


Ugyanebben a témában a korábbi írásaim a Nortel, a 3Com (új HP) majd a HP (ProCurve, régi HP) Layer 2-es discovery protokolljainak alapvető használatát mutatták be, illetve az IOS-es LLDP-t.

2012-01-24

Interfész információk Vyattán

Elképzelni is nehéz, mit össze nem keresgéltem a múltkor, hogy miképp lehet Vyatta alatt megnézni egy Ethernet interfészen a hozzá tartozó speed és duplex beállításokat. A legtöbb network OS alatt ugye ez eléggé egyértelmű, egy sima show interface vagy mondjuk 3Com/HP/Huawei vonalon egy display interface parancs kiírja, hogy 10, 100 vagy 1000 M, full vagy half duplex, auto, nem auto. A Vyatta OS azonban nem követi ezt a konvenciót, úgyhogy eddig, ha szükségem volt ilyen jellegű információra, mindig "kiléptem" a Vyatta shellből sudo -i-vel és vagy a mii-tool vagy az ethtool parancsot használtam:

root@Vyatta:~# mii-tool eth1
eth1: negotiated 1000baseT-FD flow-control, link ok


root@Vyatta:~# ethtool eth1
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: yes


Szép, szép, de ezek mégiscsak linuxos parancsok, tulajdonképpen mindig is bosszantott, hogy miért nem lehet ezt a sima Vyatta shellben megnézni. Aztán persze tök véletlenül kiderült, hogy a user a béna, természetesen  benne van ez a Vyatta shellben is, csak nem egészen ott kerestem eddig, ahol kellett volna; az ethtool kimenetét adja a a következő parancs:


admin@Vyatta:~$ show interfaces ethernet eth1 physical
Settings for eth1:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: g
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: yes
driver: tg3
version: 3.115
firmware-version: 5703-v2.22
bus-info: 0000:02:02.0

2012-01-10

DNAT szabályok tűzfalazása Vyatta alatt

Rég nem volt már teljes egészében Vyattának szentelt írás az oldalon, a napokban épp szóba is került a rendszernek egy érdekesebb tulajdonsága a munkahelyemen, így most semmi sem tarthat vissza attól, hogy mindazt, amiről ott szó volt, közzé ne tegyem. Alapvetően egyszerű dologról van szó, a Vyatta port forwarding vagy DNAT lehetőségéről, ami kombinálva némi szűréssel, könnyen káromkodásba fordulhat (megjegyzem, minden Linux rendszeren ugyanezen szisztéma szerint működik a DNAT). Mi is ez az egész pontosan? Íme a Vyatta dokumentációból kiollózott ábra, mely az egyes NAT alrendszerek, a routing folyamat és a tűzfalazás viszonyát szemlélteti:


Az ábrán a témánk szempontjából két fontos dolgot láthatunk, az egyik az, hogy a DNAT (destination NAT, avagy port forwarding, esetleg szolgáltatás publikálás) minden egyéb feldolgozási folyamat, routeolás, szűrés előtt történik meg egy beérkező csomagon. Ezzel szemben az SNAT (source NAT) a legutolsó lépés, ami csak a routeolás és a tűzfalazás után történik. A szűrés szempontjából az SNAT sima ügy, bejön a klienstől a csomag mondjuk a 192.168.0.100-as forrás IP-vel, a célcím nem a Vyatta rendszer (Dest=local? No), a tűzfal szépen átkergeti az IN, majd az OUT irányú szabályokon, végül az SNAT dobozkában leszerelik róla a 192.168.0.100-as feladói címet és ráhegesztik mondjuk feladóként az 1.2.3.4 publikus címet, illetve ezt fel is jegyzik egy táblázatba, hogy a visszatérő forgalmat le lehessen kezelni és eljusson az eredeti feladóhoz.

A DNAT egy kicsit más, arról van ugye szó, hogy az 1.2.3.4-re irányuló, pl. TCP 80-as forgalmat valójában nem a Vyatta webszervere emésztgeti, hanem a mögötte lévő NAT-olt hálóban mondjuk a 192.168.0.101-es host. Bemegy a DNAT dobozba a 1.2.3.4:80-ra küldött üzenet, odabent átalakul, és ami kijön, annak már 192.168.0.101:80 lesz a célja. Persze a dobozban ezt a csereberét megintcsak jól feljegyzik. Ezek után a routing megmondja, hogy ez a 192.168.0.101 a Vyatta LAN oldalán található cím (Dest=local? No), átmegy az IN, majd az OUT szűrőn, és kimegy a LAN-ba.

Mindez azért érdekes, mert az ember - főképp, ha vállalati tűzfalak GUI-jához szokott - a tűzfalszabályok írásakor alapból nincs NAT üzemmódban, és egy ilyen DNAT-olt 80-as portot simán úgy vesz fel a Vyatta tűzfalszabályokban, hogy a külső IP címmel számol, az 1.2.3.4:80-ra engedi be a népeket, pedig mire a tűzfalhoz eljut az 1.2.3.4:80-as csomag, addigra az már keresztülverekedte magát a DNAT-on, és 192.168.0.101:80 van benne.

Következzék egy konkrét konfig példa, ami kívülről elérhetővé teszi az 1.2.3.4:22-es és 1.2.3.4:80-as TCP portokat, a különbség annyi, hogy az SSH a Vyattán fut, a HTTP viszont NAT mögött, másik hoston. A Vyatta külső interfészének (eth0) bejövő szűrőjében mégis egy privát, belső IP cím szerepel:

firewall {
    name INET_to_INTERNAL {
        default-action drop
        rule 100 {
            action accept
            description "Allowing HTTP traffic to internal host 101"
            destination {
                address 192.168.0.101
                port 80
            }
            protocol tcp
        }
    }
    name INET_to_LOCAL {
        default-action drop
        rule 100 {
            action accept
            protocol icmp
        }
        rule 200 {
            action accept
            description "SSH access on port 22"
            destination {
                address 1.2.3.4
                port 22
            }
            protocol tcp
        }
    }
}
interfaces {
    ethernet eth0 {
        address 1.2.3.4/24
        firewall {
            in {
                name INET_to_INTERNAL
            }
            local {
                name INET_to_LOCAL
            }
        }
    }
    ethernet eth1 {
        address 192.168.1.1/24
    }
    loopback lo {
    }
}
protocols {
    static {
        route 0.0.0.0/0 {
            next-hop 1.2.3.1 {
            }
        }
    }
}
service {
    nat {
        rule 100 {
            description "DNAT for HTTP on 192.168.0.101"
            destination {
                address 1.2.3.4
                port 80
            }
            inbound-interface eth0
            inside-address {
                address 192.168.0.101
            }
            protocol tcp
            type destination
        }
        rule 200 {
            description "SNAT for internal subnet"
            outbound-interface eth0
            outside-address {
                address 1.2.3.4
            }
            source {
                address 192.168.0.0/24
            }
            type source
        }
    }
    ssh {
        port 22
        protocol-version v2
    }
}

2011-08-26

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)

2011-08-25

Vyatta image-based telepítés, frissítés

Egy jó ideje már figyelemmel kísérem a Vyatta network OS fejlődését, és gyakorlatilag a 4-es verzióktól kezdve mindig használtam is valamire az éppen aktuális kiadást. Nem feltétlenül nagy dolgokra, de egyre több éles, nem kritikus rendszerünk ezt futtatja. Most, kb. egy hónappal az új, 6.3-as verzió kiadása után, eljött az idő a frissítésre.

A frissítés lehetősége függ attól, hogy hogyan telepítettük rendszert, amit lehet disk-based (install-system parancs) és image-based (install-image parancs) módban is telepíteni. Az OS image kezelés a hatos verziók újdonsága volt, image alapon sokkal rugalmasabb felállást kapunk, egyszerre több image-ünk is lehet feltelepítve, amelyek közül a boot menüben kiválaszthatjuk, melyiket futtatnánk. Minden image-hez külön, független konfiguráció tartozik, amit importálhatunk, exportálhatunk az image-ek közt.

Úgy tűnik, hogy a fejlesztők is inkább az image alapú irányt szeretnék hosszabb távon továbbvinni: a 6.3-as kiadásban ugyanis már nincs lehetőség a frissítésre a disk-based telepítés esetében a full-upgrade paranccsal. Nem lennék meglepődve, ha néhány kiadás múlva teljesen ki is kopna a rendszerből disk-based telepítési lehetőség.

Hogyan néz ki egy image alapú telepítés? Nagyjából úgy, mint akármelyik live Linux. Felkerül a merevlemezre vagy flash memóriára a bootloader (sima GRUB2), illetve minden egyes feltelpített Vyatta image-hez készül egy könyvtár, amiben négy fontos dolog van: a legnagyobb falat az adott image (egy squashfs fájlrendszer, kb. 190MB), aztán van itt még a rendszer bebootolásához egy kernel, az intitrd és egy live-rw nevű alkönyvtár.

A bekapcsolás után a bootloader betölti a kiválasztott image-hez tartozó kernelt, majd az initrd-n keresztül behúzza az adott image-hez tarozó squashfs read only fájlrendszert (ez egyetlen image fájl a tényleges, fizikai fájlrendszerünkön), végül unionfs-sel összefésüli a squashfs tartalmát a már említett live-rw könytár tartalmával. Minden squashfsbe "fagyasztott" állapothoz képest történő változás fizikailag ebbe a live-rw könyvtárba kerül, többek közt a felhasználó által létrehozott konfiguráció is, ám az unionfs a végfelhasználó elől ezt teljesen elrejti, a felhasználó csak a hagyományos UNIX fájlrendszerstruktúrát látja a rendszer működése közben.

Mindezekről, hogy squashfs így, meg unionfs úgy, initrd erre, bootloader amarra, a Vyatta felhasználónak semmit sem kell tudnia, annyi féle Vyatta szoftver image-t tarthat a gépén, amennyit az elbír, az a néhány dolog, amit érdemes megjegyezni a következő:
  • Ha jön az új Vyatta verzió, akkor az legegyszerűbben az add system image http://www.vyatta.com/downloads/verzioszam.iso paranccsal telepíthető. A rendszer az ISO fájlból kimásolja a squashfs image-t és a többi tartozékot. A folyamat közben felajánlja az éppen futó image-hez tartozó konfiguráció átmásolását az új imagehez (bemásolja az ahhoz tartozó live-rw könyvtárba, a felhasználó számára persze az unionfs-en keresztül mutatott konfiguráció mindig a /config könyvtárában lesz megtalálható).
  • A rendszer bootolásakor kiválasztható, hogy melyik image-t szeretnénk futtatni, az alapértelmezett a set system image default-boot <image neve> paranccsal adható meg (ez beállítja a GRUB-ot).
  • A már nem használt image-től a delete system image <image neve> paranccsal lehet végleg megszabadulni.
  • A konfiguráció másolható a különféle image-ek közt, például az épp futó image-ről a "VPNteszt" nevű másik image-be így másolható át: copy file running://config/ to VPNteszt://config/

2011-05-09

PPPoE VLAN interfészen Vyatta alatt

Délután hosszasan vesződtem azzal, hogy egy VDSL modem mellé bekonfiguráljak egy Vyatta 6.2-es rendszert. Nem voltak nagy igények, csak a szokásosnak mondható dolgok, SPI tűzfal, NAT, DHCP, ilyesmi. Az egyetlen szokatlan dolog, hogy a Vyatta rendszerben egyetlen NIC-en, VLAN-okkal szerettem volna megoldani a LAN és a WAN kapcsolatot. Az interfész konfiguráció tehát első blikkre kb. így nézett ki:

interfaces {
    ethernet eth0 {
        duplex auto
        hw-id aa:aa:aa:aa:aa:aa
        speed auto
        vif 2 {
            pppoe 0 {
                connect-on-demand
                default-route auto
                mtu 1492
                name-server auto
                password DSLpassword
                user-id DSLusername
            }
        }
        vif 3 {
            address 192.168.0.1/24
        }
    }
    loopback lo {
    }
} 

Mondanom sem kell, nem ment. De hát mi a fene baja lehet? A modem elérhető volt a 2-es VLAN-on, a LAN oldalon is rendben volt a 3-as VLAN, a tesztkliens LAN oldalon megkapta DHCP-vel a szükséges adatokat a Vyattától, de valamiért a PPPoE nem jött össze. Persze rögtön kipróbáltam, hogy közvetlenül a modembe dugom a tesztklienst: csatlakozott. Jó, akkor lépjünk tovább, a tesztkliens VLAN2-ben, switchen keresztül vajon csatlakozik-e? Persze, így is működik. Hm... vajon a Vyatta-hoz használt trönk port jó? VLAN2 és VLAN3 is tagged, ahogy a Vyattán konfiguráltam? Ezzel sem volt gond. Akkor talán a Vyatta rendszerben használt NIC problémás? Neeem, simán kezeli a VLAN-okat, nincs vele gond.

Turkáltam a Vyatta doksikban, ez, ha lehetséges, még kevesebb eredménnyel zárult, hiába van a rendszerhez 1000+ oldal dokumentáció, arról, hogy Ethernet interfészen hogy lehet PPPoE-t beállítani, nem sokat mesélnek, a DSL-es példák is egytől egyig az előfizetéses SE verziójú Vyattában használható DSL modemkártyák beizzításáról szólnak, PPPoE over VLAN sehol.

Rendben, gondoltam, ha nincs más, akkor belenézünk tcpdumppal. Igen ám, de mibe? Kiderült, hogy a fizikai interfészen egy árva PPPoE-vel kapcsolatos bit sem megy át, se PADI, se PADO, semmi, hiába próbálgatom a connect interface pppoe0 parancsot. Itt azért már gyanús volt, hogy valami vyattás hülyeségbe szaladtam bele, talán nem is támogatott lehetőség a PPPoE over VLAN vagy hasonló.

Végül a Google kiköpte a választ, nem a PPPoE over VLAN a hiba forrása. Persze azóta elkevertem a linket, és már nem emlékszem, hogy mire kerestem pontosan, de mindegy is, a lényeg, hogy egy vyatta.org-os fórumbejegyzésben egy Vyatta alkalmazott leírta, hogy már egy ideje gond van ezzel a connect-on-demand dologgal, és ha azt kiszedjük a konfigból, minden jó lesz. És tényleg, a delete interfaces ethernet eth0 vif 1 pppoe 0 connect-on-demand parancs kiadása után minden a helyére került. Megjegyzem, ez azért bénaság egy olyan feltörekvő networkös cégtől, amelyik a vállalati piacra szeretne betörni. Kíváncsi lennék, hogy vajon csak az ingyenes Vyatta szoftververziókban van-e ilyen hiba vagy az előfizetéses változatokban is?

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

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

2011-01-24

Multi-VLAN bridge site-to-site VPN tunneleken Vyattával és OpenVPN-nel

Többféle megközelítése lehetséges a VLAN-ok telephelyek közötti átvitelének, ebben a posztban egy, a Vyattában nem túl régóta meglévő opcióval, az OpenVPN-nel esek neki a problémának. Alapvetően tesztről van szó, és mivel nem akartam túlságosan elbonyolítani, ezért a tesztkörnyezetben a teljes layer 2 egyetlen switchen lakik, ezen az egy switchen van az egyik telephely két VLAN-ja, a másik telephely két VLAN-ja, és persze a WAN kapcsolatot helyettesítő VLAN is. Layer 3-as funkciók (a tesztklienseket leszámítva) csak a Vyatta hostokon találhatók, ezekben csupán egyetlen NIC van, így minden interfész vagy VLAN interfész lesz vagy valamilyen egyéb virtuális interfész. A cél, hogy a két telephely között a kliensek számára transzparens layer2-es bridge épüljön fel az alábbi topológiával:


A bemutatandó módszer lehetővé teszi a VLAN ID átírást, és mivel a tesztkörnyezet layer 2-ben csupán egyetlen switch, szükség is lesz erre, de éles környezetben természetesen lehet ugyanazokat a VLAN ID-ket használni a kapcsolat mindkét oldalán. V1 és V2 lesz a két Vyatta teszt host, mindkettő egyetlen fizikai interfészen keresztül kapja meg a tagged VLAN-okat. V1 esetében ez a VLAN1, VLAN2, VLAN3, az ezeknek megfelelő interfészek értelemszerűen: eth0.1, eth0.2, eth0.3. A beállítások hasonlóak V2 esetén is, ám itt a VLAN2 átalakul VLAN20-ra a VLAN3 pedig VLAN30-ra.

Mielőtt ténylegesen belekezdenénk a VPN konfigurációba, állítsuk be a legalapvetőbb dolgokat! Szükség lesz egy VLAN1 interfészre, azon IP-re, SSH-ra, és a hostnév beállítása sem árt (a prompt csak egy kijelentkezés-bejelentkezés után vált V1-re az alapértelmezett "vyatta"-ról):
vyatta@vyatta:~$ configure
[edit] 
vyatta@vyatta# set interfaces ethernet eth0 vif 1 address 10.1.1.1/24
[edit]
vyatta@vyatta# set system host-name V1
[edit]
vyatta@vyatta# set service ssh        
[edit]
vyatta@vyatta# commit 
Restarting OpenBSD Secure Shell server: sshd.
[edit]
vyatta@vyatta# save
Saving configuration to '/opt/vyatta/etc/config/config.boot'...
Done
A továbblépés előtt hasonló  alapbeállítást igényel a V2-es Vyatta is. Ha megvagyunk, akkor jöhet a VPN: a site-to-site tunnelek felhúzásához az új OpenVPN-es Vyatta parancsokat fogjuk használni, és az egyszerűség kedvéért PSK-ra építünk. Ha jobban meggondolom, annyira azért nem új az OpenVPN a Vyattában, valamikor tavaly év elején került bele. Akárhogy is, a topológia megvalósításához két külön OpenVPN tunnelre lesz szükségünk, ezért a V1 alapbeállításai után az első feladat két kulcs létrehozása a V1-en, majd e két kulcs eljuttatása V2-re is. A kulcsok generálása a "vpn openvpn-key generate <fájlnév>" paranccsal történik:
vyatta@V1:~$ vpn openvpn-key generate /root/vtun0.key
vyatta@V1:~$ cat /root/vtun0.key  
cat: /root/vtun0.key: Permission denied
vyatta@V1:~$ sudo cat /root/vtun0.key
#
# 2048 bit OpenVPN static key
#
-----BEGIN OpenVPN Static key V1-----
0cbcd00265518db1fd8b4ded2e721396
2ee1ef306d1163b82df0b478462ae35b
5764e128b8c6f15931c2ad0d94f1a477
c7aab38ca570cc20b0aeb8da8056dd27
d70d4bdf9b705af8cfe2380f57a7c840
ae24f6a9a1f13d5da1ebc18025b8d575
dc4634625c051bfbf976b72a8f35bca5
238bd80f371df2bac0f48ccd26968917
9b86c7067bf6a927c217f81d6f6b6840
7e133cc4fc677175a5702f841b11be4e
8c56c0cfc08497d1e599162757ec848b
26f670842245af40f45670b3ef257adc
784aa1f6b1c27c83e969aab0edca8b6b
dead67a4bad7630f18838cb0871b1449
a686356a001e4d3c34ecc8743f7c6067
95027528e178fb73994241e6348c3977
-----END OpenVPN Static key V1-----
vyatta@V1:~$ 
Az első paranccsal legeneráltuk az OpenVPN PSK-t és azt a "/root/vtun0.key" fájlba mentettük. Tulajdonképpen mindegy is, hogy hová mentjük, a fájl "root:root","600" jogokkal jön létre, tehát kizárólag a root felhasználó tudja írni-olvasni, másoknak semmilyen jogosultsága nincs a fájlra, és ez jól is van így. A példában ezért nem működik elsőre a fájl tartalmának kiírása, másodszorra viszont rootként megyünk, sudo-val, ezért nincs ilyen probléma. A "vtun0.key"-hez hasonlóan generáltassunk egy "vtun1.key"-t is, ez lesz a másik tunnelhez a PSK. Ha megvannak a kulcsok, akkor SCP-vel átmásolhatjuk őket a V2-re (figyelem: a kulcsok csak a root számára olvashatók, viszont az SSH PermitRootLogin no-val fut, "sudo -i"-vel tudunk bash shellt nyitni rootként a megoldáshoz). Persze SCP helyett másolhatjuk vágólapon keresztül is a kulcsokat vagy USB-n, a lényeg, hogy ugyanazok a kulcsok legyenek fent mindkét Vyattán.

Ezek után létrehozhatjuk a V1-en az első site-to-site bridge kapcsolatot. Készítünk egy "br0" nevű bridge interfészt, amelynek a tagjai az "eth0.2" és a "vtun0" lesznek, majd beállítjuk az OpenVPN paramétereket. OpenVPN esetén szeretem kihasználni az IPSec-től eltérő adottságokat, ilyen például a Blowfish kódolás (bf128), ami - ha pusztán a szoftveres implementációkat vizsgáljuk, márpedig a Vyatta esetén csak ilyenünk van - minden létező teszt szerint gyorsabb az AES-nél, az öregecskedő 3DES-t pedig nem is érdemes egy lapon említeni vele. A "br0" és a "vtun0" beállítását a következő parancsokkal végezhetjük el a V1-en:
set interfaces bridge br0
set interfaces ethernet eth0 vif 2
set interfaces ethernet eth0 vif 2 bridge-group bridge br0
set interfaces openvpn vtun0 bridge-group bridge br0
set interfaces openvpn vtun0 encryption bf128
set interfaces openvpn vtun0 hash sha1
set interfaces openvpn vtun0 mode site-to-site
set interfaces openvpn vtun0 remote-host 10.1.1.2
set interfaces openvpn vtun0 shared-secret-key-file /root/vtun0.key
Alapvetően rendkívül hasonló lesz a "br1" és a "vtun1" is, azt az apróságot leszámítva, hogy itt az OpenVPN által alapértelmezetten használt egyetlen portot UDP 1194-ről eggyel feljebb, az UDP 1195-re tesszük mindkét oldalon (így külön datagram socketre épül a vtun1 és a vtun0), és persze az interfész nevek mások lesznek:
set interfaces bridge br1
set interfaces ethernet eth0 vif 3
set interfaces ethernet eth0 vif 3 bridge-group bridge br1
set interfaces openvpn vtun1 bridge-group bridge br1
set interfaces openvpn vtun1 encryption bf128
set interfaces openvpn vtun1 hash sha1
set interfaces openvpn vtun1 local-port 1195
set interfaces openvpn vtun1 mode site-to-site
set interfaces openvpn vtun1 remote-host 10.1.1.2
set interfaces openvpn vtun1 remote-port 1195
set interfaces openvpn vtun1 shared-secret-key-file /root/vtun1.key
A sok pötyögés után jöhet a "commit" majd a "save", és a V1-en készen is vagyunk. A V2 konfigurációja alig tér el a V1-től, "vtun0" esetén "vif2" helyett "vif20", "10.1.1.2" helyett pedig "10.1.1.1" szükséges. A V2 "vtun1" pedig "vif3" helyett "vif30"-at használ, illetve itt is 1-re végződik a VPN peer IP-je. Említettem az elején: nem feltétlenül kell átírni a V2-es Vyattán a VLAN ID-ket, a tesztkörnyezet azonban nálam csak egyetlen switchet tartalmazott layer2-ben. Ha készen vagyunk a beállításokkal, a VPN kapcsolatok állapotát a "show interfaces openvpn", illetve a "show interfaces openvpn detail" paranccsal ellenőrizhetjük, A bridge-ek állapotát a "show bridge br0" vagy "show bridge br1" paranccsal kérhetjük le.

2011-01-21

Vyatta alapok

Régebben, amikor még úgy gondoltam, hogy ismét felcsapok egy magyar IT portálon munkatársnak, már szemezgettem ezzel a network OS-szel, és többé kevésbé azóta is követem töretlen fejlődését, jómagam viszont mégsem csaptam fel semmilyen IT portálon semmiféle munkatársnak. A Vyattáról akkor leírtak ettől függetlenül természetesen továbbra is érvényben vannak, és a rendszer fejlesztőinek azóta sikerült rengeteg hasznos lehetőséget átemelni a Linux platformról a Vyatta által is támogatott elemek közé.

Nagyon sokat fejlődtek a 4-es verziók óta a VPN képességek, megjelent a WAN load balancing, jelentős átalakítás történt a tűzfal funkciókban, itt is átvették a más termékekben már jól bevált zóna koncepciót, és persze egyre több Vyatta funkció érhető el IPv6-on is. Az éppen aktuális 6.1-es Vyattában rettenetesen tetszik, hogy image-ként is lehet telepíteni, így csak a bootoláshoz szükséges fájlok és egy Squashfs image kerül fel a gépre, nem lesz rajta a hagyományos értelemben telepített Linux. Ezzel ismét egy lépéssel közelebb került a rendszer a hálózati eszközök világában megszokott konvenciókhoz. Több feltelepített image esetén boot menüben választhatunk a rendelkezésre álló "firmware"-ek közül. A rendszerhez egyetlen konfigurációs fájl tartozik, ebben a fájlban van a teljes konfiguráció, beleértve a szolgáltatásokat és azok paramétereit, a VLAN-okat, a userneveket, jelszavakat, tűzfalszabályokat, routeolási, NAT-olási beállításokat stb.

Gyorstalpaló az induláshoz:
  • Ha csak próbálgatni, tesztelni szeretnénk, nem kell telepítés, live CD-n terjesztik.
  • Bejelentkezés: user: vyatta, password: vyatta.
  • Ez nem hagyományos értelemben vett Linux, mindent el tudunk végezni a Vyatta shell saját parancsaival, ne küzdjünk a megszokott bash shellért. Ha ilyesmire vágyunk, egyszerűbb egy rendes Linuxot elővenni. Egyébként a legtöbb alapvető UNIX parancs elérhető a Vyatta shellből, csak nincs meg hozzá a tab-os autocomplete, így olyan, minta nem is létezne (a "help" paranccsal kérhető rövid összefoglaló a támogatott UNIX parancsokról).
  • Telepítéskor inkább az image alapú telepítést ("install-image" parancs) válasszuk, a régebbi módszernek ("install-system" parancs) csak akkor van előnye, ha módosítani szeretnénk a rendszer felépítésén, extra csomagokat akarunk használni, de ennyi erővel már telepíthetünk bármilyen Linuxot is, ehhez sem kell Vyatta.
  • CLI üzemmódok: operational mode ($ prompt), configuration mode (parancs: "configure", # prompt)
  • A konfiguráció hierarchikusan szervezett, node-okból és attribútumokból épül fel, a node-okat mindig kapcsos zárójellel {} határolt szövegrész követi, benne a node részleteivel, ami állhat újabb node-okból vagy attribútumokból. Pl:
  service {
     ssh {
         port 22
     }
 }
  • Konfiguráció lekérése operational módban: "show configuration", konfig módban: "show".
  • A beállítások tekergetése, módosítása (konfigurációs módban) mindig a "set" paranccsal kezdődik, utána felsoroljuk a node-okat amelyek mentén végül eljutunk a módosítani kívánt attribútumhoz (bizonyos esetekben elég csak a node-ot megadni: pl. "set service ssh"). Egy alap konfighoz, ami már lehetővé teszi a távoli adminisztrációt is SSH-n keresztül, a következő parancsokat kell kiadnunk:
set service ssh
set system host-name TESZT
set interfaces ethernet eth0 address 10.10.10.10/24
set system gateway-address 10.10.10.1
  • Konfiguráció törlése: ugyanúgy történik mint a a beállítás, ám "set" helyett "delete" a parancs eleje. Nemcsak attribútumokat, hanem teljes node-okat is törölhetünk egyben.
  • Az ilyen környezetben megszokott segítség (nyilak, tab, kérdőjel) itt is rendelkezésre áll, sőt a tab az általunk előzetesen már megadott értékekre, nevek, IP-címek, stb. is tudja az automatikus kiegészítést (sajnos nem minden node-on).
  • A módosított beállítások nem jutnak azonnal a parancs kiadása után érvényre. Konfigurálás közben bármikor megnézhetjük a konfigurációs fájl aktuális állapotát a "show" paranccsal. Azon sorok előtt, amelyeket frissen adtunk a konfigurációhoz és még nem részei az éppen futó beállításoknak egy "+" jel áll. Ugyanígy a törölt sorok előtt egy "-" jel áll.
  • A "commit" parancs konfigurációs módban aktualizálja a konfigurációs változásokat, és ténylegesen is beállítja a rendszert.
  • A "save" parancs menti a konfigurációt (hogy egy újraindítás után is meglegyen).
  • Konfigurációs módból való kilépés: "exit".