Ahoj! V předchozím příspěvku jsem popsal fungování naší služby MultiSIM v oblasti rezervace a vyvážení kanálů. Jak již bylo zmíněno, klienty k síti připojujeme přes VPN, a dnes vám řeknu trochu více o VPN a našich možnostech v této oblasti.
Začněme s tím, že jako poskytovatel telekomunikačních služeb máme svou obrovskou MPLS síť, která je pro klienty pevných řad rozdělena na dva hlavní segmenty — ten, který se používá přímo pro přístup k síti Internet, a ten, který se používá pro vytváření izolovaných sítí — a právě tímto segmentem MPLS prochází provoz IPVPN (L3 OSI) a VPLAN (L2 OSI) pro naše firemní klienty.
Obvykle je připojení klienta realizováno následujícím způsobem.
K kanceláři klienta je zajištěna přístupová linka z nejbližšího bodu přítomnosti sítě (uzlu MEN, PРL, BSSS, FTTB atd.) a dále, kanál je zakódován v transportní síti k odpovídajícímu RE-MPLS směrovači, na kterém ho vyvedeme do speciálně vytvořeného pro klienta VRF se zohledněním profilového provozu, který je pro klienta potřebný (značky profilu se vybírají pro každý přístupový port na základě hodnotiprecedence 0,1,3,5).
Pokud z nějakého důvodu nemůžeme plně zorganizovat poslední míli pro klienta, například pokud se kancelář klienta nachází v business centru, kde je v prioritě jiný poskytovatel, nebo v blízkosti prostě není naše přítomnost, pak dříve klienti museli vytvářet několik IPVPN sítí u různých poskytovatelů (nejsou to zrovna cenově výhodné architektury) nebo se sami snažit vyřešit problémy s organizací přístupu k jejich VRF přes Internet.
Mnozí to dělali pomocí instalace IPVPN internetového brány — instalovali hraniční směrovač (hardwarový nebo jakékoli řešení založené na Linuxu), připojovali k němu jedním portem IPVPN kanál a druhým — internetový kanál, spouštěli na něm svůj VPN server a připojovali uživatele prostřednictvím svého vlastního VPN brány. Přirozeně, takový systém přináší i zátěže: podobnou infrastrukturu je třeba umět budovat a, co je nejméně pohodlné — provozovat a rozvíjet.
Aby usnadnit život naszym klientům, zřídili jsme centralizovaný VPN hub a organizovali podporu připojení přes internet pomocí IPSec. Klienti nyní potřebují pouze nastavit svůj router pro práci s naším VPN hubem skrze IPSec tunel přes jakýkoli veřejný internet, a my převedeme provoz tohoto klienta do jeho VRF.
Komu se to hodí
- Těm, kteří již mají velkou IPVPN síť a potřebují nové připojení v krátkém čase.
- Všem, kdo z nějakého důvodu chtějí přesunout část provozu z veřejného internetu do IPVPN, ale dříve čelili technickým omezením spojeným s několika poskytovateli služeb.
- Těm, kteří v současnosti mají několik oddělených VPN sítí u různých operátorů. Existují klienti, kteří úspěšně organizovali IPVPN jak od Beeline, tak od MegaFonu, i od Rostelekomu atd. Aby to bylo jednodušší, mohou zůstat pouze na našem jednotném, VPN, všechny ostatní kanály jiných operátorů přepnout na internet, po čemž se připojí k IPVPN Beeline přes IPSec a internet od těchto operátorů.
- Těm, kteří již mají IPVPN síť, překrývající se s Internetem.
Pokud vše zprovozníme u nás, klienti získají plnou podporu VPN, významnou rezervaci infrastruktury a standardní nastavení, která budou fungovat na jakémkoli obvyklém routeru (ať už je to Cisco nebo Mikrotik, hlavně aby podporoval IPSec/IKEv2 se standardizovanými metodami autentizace). Mimochodem, co se týče IPSec — v tuto chvíli podporujeme pouze ten, ale plánujeme spustit plnou podporu také pro OpenVPN a Wireguard, aby klienti nebyli závislí na protokolu a mohli snadno přesunout vše k nám, a také chceme začít připojovat klienty z počítačů a mobilních zařízení (integrovaná řešení v OS, Cisco AnyConnect a strongSwan a podobné). Při takovém přístupu lze de facto výstavbu infrastruktury s jistotou svěřit operátorovi, ponechávajíc pouze nastavení CPE nebo hostitele.
Jak probíhá proces připojení pro režim IPSec:
- Klient zasílá žádost svému manažerovi, ve které uvádí požadovanou rychlost připojení, profil provozu a parametry IP adresace pro tunel (výchozí podsíť s maskou /30) a typ směrování (statické nebo BGP). Pro přenos směrování do lokálních sítí klienta v připojené kanceláři se používají mechanismy IKEv2 fáze protokolu IPSec pomocí odpovídajících nastavení na klientském routeru, nebo jsou inzerovány prostřednictvím BGP v MPLS z uvedeného soukromého BGP AS klientem. Tímto způsobem je informace o směrování klientských sítí plně kontrolována klientem prostřednictvím nastavení klientského routeru.
- V odpovědi od svého manažera obdrží klient účetní údaje pro připojení do svého VRF ve formátu:
- IP adresa VPN-HUB
- Uživatelské jméno
- Heslo pro autentizaci
- Nastavuje SRV, níže, pro příklad dva varianty základní konfigurace:Varianta pro Cisco:
crypto ikev2 keyring BeelineIPsec_keyring
peer Beeline_VPNHub
address 62.141.99.183 –VPN koncentrátor Beeline
pre-shared-key
!
Pro variantu se statickým směrováním mohou být směry do sítí dostupných přes Vpn-hub nastaveny v konfiguraci IKEv2 a automaticky se objeví jako statické směry v tabulce směrování SRV. Tato nastavení je také možné provést standardním způsobem zadávání statických směrování (viz níže).crypto ikev2 authorization policy FlexClient-author
Směr do sítí za SRV routerem – povinné nastavení při statickém směrování mezi SRV a PE. Přenos dat směrování na PE se provádí automaticky při spuštění tunelu prostřednictvím interakce IKEv2.
route set remote ipv4 10.1.1.0 255.255.255.0 –Lokální síť kanceláře
!
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 –Adresa tunelu
tunnel source GigabitEthernet0/2 –Rozhraní pro přístup k Internetu
tunnel mode ipsec ipv4
tunnel destination dynamic
tunnel protection ipsec profile default
!
Směry do soukromých sítí klienta, dostupné přes VPN koncentrátor Beeline, lze nastavit staticky.ip route 172.16.0.0 255.255.0.0 Tunnel1
ip route 192.168.0.0 255.255.255.0 Tunnel1Varianta pro Huawei (ar160/120):
ike local-name
#
acl name ipsec 3999
pravidlo 1 povolit ip zdroj 10.1.1.0 0.0.0.255 –Lokální síť kanceláře
#
aaa
služba-schemat IPSEC
cesta nastavit acl 3999
#
ipsec návrh ipsec
esp autentizační-algoritmus sha2-256
esp šifrovací-algoritmus aes-256
#
ike návrh default
šifrovací-algoritmus aes-256
dh group2
autentizační-algoritmus sha2-256
autentizační-metoda pre-share
integritní-algoritmus hmac-sha2-256
prf hmac-sha2-256
#
ike peer ipsec
pre-shared-key jednoduché
local-id-type fqdn
remote-id-type ip
vzdálená-adresa 62.141.99.183 –VPN koncentrátor Beeline
služba-schemat IPSEC
config-exchange požadavek
config-exchange nastav přijmout
config-exchange nastav poslat
#
ipsec profil ipsecprof
ike-peer ipsec
návrh ipsec
#
rozhraní Tunnel0/0/0
ip address 10.20.1.2 255.255.255.252 –Adresa tunelu
tunnel-protocol ipsec
zdroj GigabitEthernet0/0/1 –Rozhraní pro přístup k Internetu
ipsec profil ipsecprof
#
Trasy k privátním sítím klienta, dostupné přes VPN koncentrátor Billa, lze zadat statickyip statická cesta 192.168.0.0 255.255.255.0 Tunnel0/0/0
ip statická cesta 172.16.0.0 255.255.0.0 Tunnel0/0/0
Vytvořená schéma spojení vypadá přibližně takto:
Pokud klient nemá žádné příklady základní konfigurace, obvykle mu pomáháme je vytvořit a zpřístupnit pro ostatní.
Zbývá připojit CPE k Internetu, provést ping na cílovou část VPN tunelu a na nějaký hostitel uvnitř VPN, a vše, můžeme považovat za úspěšné připojení.
V příštím článku se podělíme o to, jak jsme tuto schéma zkombinovali s IPSec a MultiSIM Zálohováním pomocí CPE Huawei: nainstalujeme našim klientům naše CPE Huawei, ve kterém lze využít nejen kabelový internet kanál, ale i 2 různá SIM karty, a CPE automaticky rekonstruuje IPSec tunel buď přes kabelový WAN, nebo přes rádio (LTE#1/LTE#2), čímž dosáhneme vysoké odolnosti konečné služby.
Zvláštní poděkování za přípravu tohoto článku (a vlastně autorům těchto technických řešení) kolegům z našeho RnD!
Zdroj: habr.com
