Helló! A korábbi bejegyzésben a MultiSIM szolgáltatásunk működését írtam le a tartalék és elosztás csatornáknál. Ahogy említettem, az ügyfeleket VPN-en keresztül kapcsoljuk a hálózatra, és ma egy kicsit többet mesélek a VPN-ről és az e téren nyújtott lehetőségeinkről.
Érdemes azzal kezdeni, hogy nekünk, mint telekommunikációs szolgáltatónak, van egy hatalmas MPLS-hálózatunk, amelyet a fix vonalas ügyfeleknek két fő szegmensre osztunk — az egyik a közvetlen internet-hozzáféréshez, a másik pedig az elszigetelt hálózatok létrehozásához használatos — és ezen a szegmensen keresztül halad az IPVPN (L3 OSI) és VPLAN (L2 OSI) forgalom vállalati ügyfeleink számára.
Általában az ügyfél csatlakoztatása a következő módon történik.
A legközelebbi Hálózati Jelenlét Ponttól (MEN csomópont, P2P, BSSS, FTTB stb.) vezetjük le az ügyfél irodájához a hozzáférési vonalat, és a csatorna a megfelelő RE-MPLS routerre van bejegyezve, ahol egy speciálisan az ügyfél számára létrehozott VRF-en keresztül irányítjuk, figyelembe véve a forgalmi profilt, amelyre az ügyfélnek szüksége van (a profil címkék az egyes hozzáférési portokhoz az ip precedence 0,1,3,5 értékek alapján kerülnek kiválasztásra).
Ha valamilyen oknál fogva nem tudjuk teljes körűen megoldani az ügyfél utolsó mérföldjét, például ha az ügyfél irodája egy üzleti központban található, ahol egy másik szolgáltató van előnyben, vagy egyszerűen nincs a közelben jelenlétünk pontja, akkor korábban az ügyfeleknek több IPVPN-hálózatot kellett létrehozniuk különböző szolgáltatóknál (ami nem a legköltséghatékonyabb architektúra) vagy saját maguknak kellett megoldaniuk a hozzáférést a saját VRF-jükhöz az interneten keresztül.
Sokan ezt az IPVPN internetes átjáró telepítésével oldották meg — határ Routert (hardveres vagy Linux alapú megoldás) állítottak fel, amelyhez egy porton IPVPN-csatornát csatlakoztattak, a másikon pedig egy internetes csatornát, létrehozták a saját VPN-szerverüket és a felhasználókat a saját VPN-átjárójukon keresztül csatlakoztatták. Természetesen, ez a séma terheket is hoz magával: ilyen infrastruktúrát tudni kell építeni, és ami a legkényelmetlenebb — üzemeltetni és fejleszteni.
Az ügyfeleink életének megkönnyítése érdekében központi VPN-hubot állítottunk fel, és szervezett támogatást nyújtunk az interneten keresztül történő csatlakozásokhoz IPSec használatával. Tehát most az ügyfeleknek csak a routerüket kell konfigurálniuk, hogy az IPSec-alagúton keresztül csatlakozzanak a VPN-hubunkhoz, és mi kiadjuk ennek az ügyfélnek a forgalmát a saját VRF-jében.
Kinek lesz hasznos
- Akiknek már létezik egy nagy IPVPN-hálózata, és gyorsan új csatlakozásokra van szükségük.
- Mindenkinek, akinek valamilyen okból át kellene vinnie a forgalmát a nyilvános internetről IPVPN-re, de korábban technikai korlátokkal kellett szembenéznie, több szolgáltató kapcsán.
- Akiknek jelenleg több széttagolt VPN-hálózatuk van különböző szolgáltatóknál. Vannak ügyfelek, akiknek sikeresen megszervezték az IPVPN-jüket a Beeline, a Megafon, a Rosztel-kom és így tovább. Hogy egyszerűbb legyen, érdemes csak a mi egyedüli megoldásunkra támaszkodni, VPN, az összes többi szolgáltató csatornáját átállítani az internetre, majd csatlakozni a Beeline IPVPN-hez IPSec-en keresztül és a vonatkozó szolgáltatók internetén.
- Akiknek már van IPVPN-hálózatuk, amely az internetre épül.
Ha mindent nálunk fejlesztettek ki, akkor az ügyfelek teljeskörű VPN-támogatást, komoly infrastruktúra-redundanciát és azokat a tipikus beállításokat kapják, amelyek bármilyen, az ügyfél által megszokott routeren működni fognak (legyen az akár Cisco, akár Mikrotik, a lényeg, hogy megfelelően támogassa az IPSec/IKEv2-t a szabványos hitelesítési módszerekkel). Amúgy, az IPSec kérdésében — jelenleg csak ezt támogatjuk, de tervezzük, hogy az OpenVPN és Wireguard teljes körű működését is beindítjuk, hogy az ügyfelek ne függjenek a protokolltól, és még egyszerűbben átköltözhessenek hozzánk, valamint szeretnénk elkezdeni az ügyfelek csatlakoztatását számítógépekről és mobil eszközökről (a beépített OS megoldásokkal, Cisco AnyConnect és strongSwan és hasonlóak). Ilyen megközelítés esetén a gyakorlatban a infrastruktúra kiépítése nyugodtan átadható a szolgáltatónak, csak a CPE vagy a hoszt beállítását hagyva magunknak.
Hogyan zajlik a csatlakozási folyamat IPSec üzemmódban:
- A kliens a menedzserének benyújt egy kérelmet, amelyben megadja a szükséges csatlakozási sebességet, a forgalmi profilt és az IP-címzési paramétereket a tunelhez (alapértelmezett alhálózat /30 maszk) és az irányítás típusát (statikus vagy BGP). A kliens irodájába való helyi hálózatokhoz történő útvonalak átadásához az IKEv2 protokoll fázisának mechanizmusait használják, a megfelelő beállításokkal a kliens útválasztón, vagy BGP-n keresztül hirdetik az MPLS-be, az ügyfél által megadott privát BGP AS szerint. Így az ügyfélnet hálózatainak útvonalairól az információ teljes mértékben az ügyfél által ellenőrzött, a kliens útválasztó beállításain keresztül.
- Az ügyfél a menedzserétől megkapja a számlázási adatokat, amelyeket be kell illesztenie az RVF-be, például:
- VPN-HUB IP-cím
- Bejelentkezés
- Hitelesítési jelszó
- A CPE-t az alábbiakban, két alapkonfigurációs lehetőség példájaként állítja be:Cisco lehetőség:
crypto ikev2 keyring BeelineIPsec_keyring
peer Beeline_VPNHub
address 62.141.99.183 –Beeline VPN koncentrátor
pre-shared-key
!
A statikus irányítási lehetőségnél az útvonalakat a Vpn-hubhoz elérhető hálózatokhoz az IKEv2 beállításokban megadhatók, és automatikusan statikus útvonalakként megjelennek a CPE útválasztó táblázatában. Ezeket a beállításokat hagyományos módszerrel is megtehetjük statikus útvonalak megadásával (lásd alább).crypto ikev2 authorization policy FlexClient-author
Az IKEv2 kapcsolat nélküli CPE-útvonal beállítása kötelező statikus irányítás esetén a CPE és a PE között. Az útvonalinformációk átadása a PE-nek automatikusan történik a tunel emelésekor az IKEv2 folyamaton keresztül.
route set remote ipv4 10.1.1.0 255.255.255.0 –Iroda helyi hálózata
!
crypto ikev2 profile BeelineIPSec_profile
identity local
authentication local pre-share
authentication remote pre-share
keyring local BeelineIPsec_keyring
aaa authorization group psk list group-author-list FlexClient-author
!
crypto ikev2 client flexvpn BeelineIPsec_flex
peer 1 Beeline_VPNHub
client connect Tunnel1
!
crypto ipsec transform-set TRANSFORM1 esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto ipsec profile default
set transform-set TRANSFORM1
set ikev2-profile BeelineIPSec_profile
!
interface Tunnel1
ip address 10.20.1.2 255.255.255.252 –Tuner címe
tunnel source GigabitEthernet0/2 –Internet elérési interfész
tunnel mode ipsec ipv4
tunnel destination dynamic
tunnel protection ipsec profile default
!
A Beeline VPN koncentrátoron keresztül elérhető ügyfélhálózatok statikus módon is megadhatók.ip route 172.16.0.0 255.255.0.0 Tunnel1
ip route 192.168.0.0 255.255.255.0 Tunnel1Huawei (ar160/120) lehetőség:
ike local-name
#
acl name ipsec 3999
szabály 1 engedélyez ip forrás 10.1.1.0 0.0.0.255 –Iroda helyi hálózata
#
aaa
szolgáltatás-vázlat IPSEC
útvonal beállítás acl 3999
#
ipsec javaslat ipsec
esp hitelesítési algoritmus sha2-256
esp titkosítási algoritmus aes-256
#
ike javaslat alapértelmezett
titkosítási algoritmus aes-256
dh csoport2
hitelesítési algoritmus sha2-256
hitelesítési módszer előre megosztott
integritási algoritmus hmac-sha2-256
prf hmac-sha2-256
#
ike partner ipsec
előre megosztott kulcs egyszerű
helyi-azonosító-típus fqdn
távoli-azonosító-típus ip
távoli-cím 62.141.99.183 –Beeline VPN koncentrátor
szolgáltatás-vázlat IPSEC
config-exchange kérés
config-exchange beállítás elfogadása
config-exchange beállítás küldése
#
ipsec profil ipsecprof
ike-partner ipsec
javaslat ipsec
#
interfész Tunnel0/0/0
ip address 10.20.1.2 255.255.255.252 –Tuner címe
alagut-protokoll ipsec
forrás GigabitEthernet0/0/1 –Internet elérési interfész
ipsec profil ipsecprof
#
Az ügyfél privát hálózatai, amelyek a Beeline VPN koncentrátora által hozzáférhetők, statikusan adhatók megip útvonal-statikus 192.168.0.0 255.255.255.0 Tunnel0/0/0
ip útvonal-statikus 172.16.0.0 255.255.0.0 Tunnel0/0/0
A kialakuló kommunikációs minta körülbelül így néz ki:
Ha az ügyfélnek nincsenek példák az alapvető konfigurációra, akkor általában segítünk azok megalkotásában és megosztjuk a többiekkel.
Most már csatlakozni kell a CPE-hez az internethez, pingelni a VPN-alagút megfelelő oldalát és valamilyen hosztot a VPN-en belül, és kész, az összeköttetés létrejött.
A következő cikkben elmondjuk, hogyan kombináltuk ezt a sémát az IPSec-szel és a MultiSIM tartalékoszközökkel a Huawei CPE segítségével: ügyfeleinknek telepítjük a Huawei CPE-t, amely nemcsak vezetékes internetkapcsolatot, hanem 2 különböző SIM-kártyát is használhat, és a CPE automatikusan átépíti az IPSec alagutat vagy a vezetékes WAN-on, vagy a rádión keresztül (LTE#1/LTE#2), megvalósítva a végső szolgáltatás magas rendelkezésre állását.
Külön köszönet azért, hogy elkészítették ezt a cikket (és magukért a technikai megoldások szerzőiért) a kollégák a RnD-ből!
Forrás: habr.com
