Hallo! In de vorige post Ik heb de werking van onze MultiSIM-service beschreven op het gebied van reservering en belasting kanalen. Zoals eerder vermeld, verbinden we klanten met het netwerk via VPN, en vandaag zal ik iets meer vertellen over VPN en onze mogelijkheden op dit gebied.
Laten we beginnen met het feit dat we als telecomoperator een enorm MPLS-netwerk hebben, dat voor klanten van vaste verbindingen is verdeeld in twee hoofsegmenten: hetgene dat wordt gebruikt voor directe toegang tot het Internet, en hetgene dat wordt gebruikt voor het creĆ«ren van geĆÆsoleerde netwerken ā en via dit MPLS-segment loopt het IPVPN-verkeer (L3 OSI) en VPLAN (L2 OSI) voor onze zakelijke klanten.
Gewoonlijk gebeurt de aansluiting van de klant als volgt.
Er wordt een toegangslijn van het dichtstbijzijnde Point of Presence van het netwerk (node MEN, P2P, BSSS, FTTB, enz.) naar het kantoor van de klant gelegd, en vervolgens wordt het kanaal door de transportnetwerk geregistreerd tot de overeenkomstige PE-MPLS-router, waar we het in een speciaal voor de klant gecreƫerde VRF afleiden rekening houdend met het verkeersprofiel dat de klant nodig heeft (de profieldelen worden voor elke toegangspoort gekozen op basis van de waarden van ip precedence 0,1,3,5).
Als we om de een of andere reden de laatste mijl voor de klant niet volledig kunnen organiseren, bijvoorbeeld als het kantoor van de klant zich in een kantoorgebouw bevindt waar een andere provider prioriteit heeft, of als onze presence point gewoon niet in de buurt is, moesten klanten vroeger meerdere IPVPN-netwerken bij verschillende providers creƫren (een architectuur die niet de goedkoopste is) of zelf de problemen met toegang tot hun VRF bovenop het Internet oplossen.
Veel mensen deden dit door een IPVPN-internet gateway te installeren ā ze installeerden een randrouter (hardwarematige of een oplossing op basis van Linux), sloten Ć©Ć©n poort aan op het IPVPN-kanaal en de andere op het Internet-kanaal, en startten hun eigen VPN-server en sloten gebruikers aan via hun eigen VPN-gateway. Het spreekt voor zich dat deze opzet ook lastige aspecten met zich meebrengt: zo'n infrastructuur moet je kunnen opbouwen en, wat het meest ongemakkelijk is ā exploiteren en ontwikkelen.
Om het leven van onze klanten te vereenvoudigen, hebben we een gecentraliseerde VPN-hub opgezet en ondersteuning georganiseerd voor verbindingen over het internet met behulp van IPSec. Dit betekent dat klanten nu slechts hun router hoeven in te stellen om samen te werken met onze VPN-hub via een IPSec-tunnel over elk publiek internet, en wij zullen het verkeer van die klant in zijn VRF vrijgeven.
Voor wie het nuttig is
Ā
- Voor degenen die al een groot IPVPN-netwerk hebben en behoefte hebben aan nieuwe verbindingen in korte tijd.
- Voor iedereen die om bepaalde redenen een deel van het verkeer van het publieke internet naar IPVPN wil verplaatsen, maar eerder technische beperkingen is tegengekomen in verband met meerdere dienstverleners.
- Voor degenen die momenteel verschillende losse VPN-netwerken hebben bij verschillende telecomoperators. Er zijn klanten die succesvol IPVPN hebben georganiseerd van zowel Beeline als Megafon, evenals Rostelecom, enz. Om het eenvoudiger te maken, kunnen ze alleen bij onze uniforme blijven. VPN, alle andere kanalen van andere operators omzetten naar internet, waarna ze verbinding kunnen maken met IPVPN van Beeline via IPSec en internet van deze operators.
- Voor degenen die al een IPVPN-netwerk hebben dat over het internet is gelegd.
Als alles bij ons wordt uitgerold, krijgen klanten volledige ondersteuning voor VPN, serieuze infrastructuurreserveringen en standaardinstellingen die werken op elke vertrouwde router (of het nu Cisco of Mikrotik is, zolang deze maar goed IPSec/IKEv2 met gestandaardiseerde authenticatiemethoden kan ondersteunen). Overigens, wat betreft IPSec ā momenteel ondersteunen we alleen dit, maar het is onze bedoeling om ook OpenVPN en Wireguard te lanceren, zodat klanten niet afhankelijk zijn van het protocol en het nog eenvoudiger hebben om alles naar ons over te zetten, en we willen ook beginnen met het aansluiten van klanten via computers en mobiele apparaten (ingebouwde oplossingen in het besturingssysteem, Cisco AnyConnect en strongSwan en soortgelijke). Met deze aanpak kan de infrastructuurbouw de facto met vertrouwen aan de operator worden overgedragen, terwijl alleen de configuratie van de CPE of host wordt overgelaten.
Hoe verloopt het proces van verbinding maken in IPSec-modus:
- De klant dient een aanvraag in bij zijn manager waarin hij de benodigde snelheid van de verbinding, het verkeersprofiel en de parameters van de IP-adressering voor de tunnel opgeeft (standaard is het subnet met een masker /30) en het type routering (statisch of BGP). Voor het doorgeven van routes naar de lokale netwerken van de klant in het aangesloten kantoor worden de IKEv2-fase mechanismen van het IPSec-protocol gebruikt met de bijbehorende instellingen op de router van de klant, of ze worden aangekondigd via BGP in MPLS uit het door de klant opgegeven private BGP AS. Op deze manier wordt de informatie over de routes van de klantnetwerken volledig beheerd door de klant via de instellingen op de router van de klant.
- Als antwoord van zijn manager ontvangt de klant de accountgegevens voor opname in zijn VRF van het type:
- IP-adres VPN-HUB
- Inlognaam
- Authenticatie wachtwoord
- Stelt de CPE in, hieronder, als voorbeeld twee varianten van een basisconfiguratie:Variant voor Cisco:
crypto ikev2 keyring BeelineIPsec_keyring
peer Beeline_VPNHub
address 62.141.99.183 ā VPN concentrator Beeline
pre-shared-key
!
Voor de variant met statische routering kunnen de routes naar de netwerken die bereikbaar zijn via de Vpn-hub in de IKEv2-instelling worden aangegeven en ze verschijnen automatisch als statische routes in de CPE-routeringstabel. Deze instellingen kunnen ook op de standaard manier voor het opgeven van statische routes worden uitgevoerd (zie hieronder).crypto ikev2 authorization policy FlexClient-author
De route naar de netwerken achter de CPE-router is een verplichte instelling bij statische routering tussen CPE en PE. Het verzenden van de routeringsdata naar PE gebeurt automatisch wanneer de tunnel wordt opgezet via de IKEv2-interactie.
route set remote ipv4 10.1.1.0 255.255.255.0 ā Lokale netwerk van het kantoor
!
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 ā Tunneladres
tunnel source GigabitEthernet0/2 ā Internettoegang-interface
tunnel mode ipsec ipv4
tunnel destination dynamic
tunnel protection ipsec profile default
!
Routes naar private netwerken van de klant, toegankelijk via de VPN concentrator Beeline, kunnen statisch worden opgesteld.ip route 172.16.0.0 255.255.0.0 Tunnel1
ip route 192.168.0.0 255.255.255.0 Tunnel1Variant voor Huawei (ar160/120):
ike local-name
#
acl name ipsec 3999
regel 1 staat ip bron 10.1.1.0 0.0.0.255 toe ā Lokale netwerk van het kantoor
#
aaa
service-schema IPSEC
route set acl 3999
#
ipsec voorstel ipsec
esp authenticatie-algoritme sha2-256
esp versleutelingsalgoritme aes-256
#
ike voorstel standaard
versleutelingsalgoritme aes-256
dh groep2
authenticatie-algoritme sha2-256
authenticatiemethode pre-share
integriteitsalgoritme hmac-sha2-256
prf hmac-sha2-256
#
ike peer ipsec
pre-shared-key simpel
lokaal-id-type fqdn
remote-id-type ip
remote-adres 62.141.99.183 ā VPN concentrator Beeline
service-schema IPSEC
config-uitwisseling verzoek
config-uitwisseling set accept
config-uitwisseling set send
#
ipsec profiel ipsecprof
ike-peer ipsec
voorstel ipsec
#
interface Tunnel0/0/0
ip address 10.20.1.2 255.255.255.252 ā Tunneladres
tunnel-protocol ipsec
bron GigabitEthernet0/0/1 ā Internettoegang-interface
ipsec profiel ipsecprof
#
Routes naar de private netwerken van de klant, toegankelijk via de Beeline VPN concentrator, kunnen statisch worden ingesteldip route-static 192.168.0.0 255.255.255.0 Tunnel0/0/0
ip route-static 172.16.0.0 255.255.0.0 Tunnel0/0/0
De resulterende communicatieschema ziet er ongeveer zo uit:
Als er geen voorbeelden van basisconfiguraties zijn voor de klant, helpen we meestal bij het opstellen ervan en maken deze beschikbaar voor anderen.
Het enige wat resteert is de CPE aansluiten op het internet, een ping uitvoeren naar de responszijde van de VPN-tunnel en naar een host binnen de VPN, en dan kunnen we concluderen dat de verbinding tot stand is gebracht.
In het volgende artikel vertellen we hoe we dit schema hebben gecombineerd met IPSec en MultiSIM Redundantie met behulp van CPE Huawei: we installeren onze Huawei CPE bij klanten, die niet alleen een vaste internetverbinding kan gebruiken, maar ook 2 verschillende SIM-kaarten, en de CPE bouwt automatisch de IPSec-tunnel ofwel via de vaste WAN of via radio (LTE#1/LTE#2), wat resulteert in een hoge beschikbaarheid van de uiteindelijke service.
Een speciale dank voor het opstellen van dit artikel (en, daadwerkelijk, de auteurs van deze technische oplossingen) aan onze collega's van RnD!
Bron: habr.com
