Hallå! I
Det är värt att börja med att vi som teleoperatör har ett eget enormt MPLS-nät, som för fasta kunder är uppdelat i två huvudsegment – det som används direkt för att komma åt Internet, och det som är används för att skapa isolerade nätverk — och det är genom detta MPLS-segment som IPVPN (L3 OSI) och VPLAN (L2 OSI) trafikflöden för våra företagskunder.
Vanligtvis sker en klientanslutning enligt följande.
En accesslinje läggs till kundens kontor från närmaste närvaropunkt i nätverket (nod MEN, RRL, BSSS, FTTB, etc.) och vidare registreras kanalen genom transportnätet till motsvarande PE-MPLS router, på vilken vi matar ut den till en speciellt skapad för VRF-klienten, med hänsyn till trafikprofilen som klienten behöver (profiletiketter väljs för varje åtkomstport, baserat på ip-precedensvärdena 0,1,3,5, XNUMX).
Om vi av någon anledning inte helt kan organisera den sista milen för kunden, till exempel om kundens kontor är beläget i ett företagscenter, där en annan leverantör är en prioritet, eller vi helt enkelt inte har vår närvaropunkt i närheten, då tidigare kunder var tvungen att skapa flera IPVPN-nätverk hos olika leverantörer (inte den mest kostnadseffektiva arkitekturen) eller självständigt lösa problem med att organisera åtkomst till din VRF över Internet.
Många gjorde detta genom att installera en IPVPN Internet-gateway - de installerade en gränsrouter (hårdvara eller någon Linux-baserad lösning), kopplade en IPVPN-kanal till den med en port och en Internetkanal med den andra, startade sin VPN-server på den och kopplade användare via sin egen VPN-gateway. Naturligtvis skapar ett sådant system också bördor: sådan infrastruktur måste byggas och, mest obekvämt, drivas och utvecklas.
För att göra livet enklare för våra kunder installerade vi en centraliserad VPN-hubb och organiserade stöd för anslutningar över Internet med IPSec, det vill säga nu behöver kunderna bara konfigurera sin router för att fungera med vår VPN-hubb via en IPSec-tunnel över alla offentliga Internet , och vi Låt oss släppa denna klients trafik till dess VRF.
Vem kommer att behöva
- För dig som redan har ett stort IPVPN-nätverk och behöver nya anslutningar på kort tid.
- Den som av någon anledning vill överföra en del av trafiken från det publika Internet till IPVPN, men tidigare stött på tekniska begränsningar kopplade till flera tjänsteleverantörer.
- För dig som för närvarande har flera olika VPN-nätverk mellan olika telekomoperatörer. Det finns kunder som framgångsrikt har organiserat IPVPN från Beeline, Megafon, Rostelecom, etc. För att göra det enklare kan du bara stanna på vår enda VPN, byta alla andra kanaler hos andra operatörer till Internet och sedan ansluta till Beeline IPVPN via IPSec och Internet från dessa operatörer.
- För dig som redan har ett IPVPN-nätverk överlagrat på Internet.
Om du distribuerar allt hos oss får kunderna fullfjädrad VPN-support, seriös infrastrukturredundans och standardinställningar som fungerar på vilken router de är vana vid (var det Cisco, till och med Mikrotik, huvudsaken är att den kan stödja ordentligt IPSec/IKEv2 med standardiserade autentiseringsmetoder). Förresten, om IPSec - just nu stöder vi det bara, men vi planerar att lansera fullfjädrad drift av både OpenVPN och Wireguard, så att klienter inte kan lita på protokollet och det är ännu lättare att ta och överföra allt till oss, och vi vill också börja koppla upp klienter från datorer och mobila enheter (lösningar inbyggda i OS, Cisco AnyConnect och strongSwan och liknande). Med detta tillvägagångssätt kan de facto-konstruktionen av infrastrukturen på ett säkert sätt överlämnas till operatören, så att endast konfigurationen av CPE eller värden kvarstår.
Hur fungerar anslutningsprocessen för IPSec-läge:
- Klienten lämnar en förfrågan till sin chef där han anger den erforderliga anslutningshastigheten, trafikprofilen och IP-adresseringsparametrarna för tunneln (som standard ett subnät med en /30-mask) och typen av routing (statisk eller BGP). För att överföra rutter till klientens lokala nätverk i det anslutna kontoret, används IKEv2-mekanismerna för IPSec-protokollfasen med hjälp av lämpliga inställningar på klientroutern, eller så annonseras de via BGP i MPLS från den privata BGP AS som anges i klientens applikation . Således kontrolleras information om rutter för klientnätverk helt av klienten genom inställningarna för klientroutern.
- Som svar från sin chef får kunden redovisningsdata för inkludering i sin VRF av formuläret:
- VPN-HUB IP-adress
- inloggning
- Autentiseringslösenord
- Konfigurerar CPE, nedan, till exempel två grundläggande konfigurationsalternativ:
Alternativ för Cisco:
krypto ikev2 nyckelring BeelineIPsec_nyckelring
peer Beeline_VPNHub
adress 62.141.99.183 –VPN-hub Beeline
fördelad nyckel <Autentiseringslösenord>
!
För det statiska routingalternativet kan rutter till nätverk som är tillgängliga via Vpn-hubben anges i IKEv2-konfigurationen och de kommer automatiskt att visas som statiska rutter i CE-routingtabellen. Dessa inställningar kan också göras med standardmetoden för att ställa in statiska rutter (se nedan).crypto ikev2 auktoriseringspolicy FlexClient-författare
Rutt till nätverk bakom CE-routern – en obligatorisk inställning för statisk routing mellan CE och PE. Överföringen av ruttdata till PE utförs automatiskt när tunneln höjs genom IKEv2-interaktion.
route set remote ipv4 10.1.1.0 255.255.255.0 -Kontors lokala nätverk
!
krypto ikev2 profil BeelineIPSec_profile
identitet lokal <login>
autentisering lokal fördelning
autentisering fjärrfördelning
nyckelring lokal BeelineIPsec_nyckelring
aaa behörighetsgrupp psk lista grupp-författare-lista FlexClient-författare
!
krypto ikev2 klient flexvpn BeelineIPsec_flex
peer 1 Beeline_VPNHub
klientanslutning Tunnel1
!
crypto ipsec transform-set TRANSFORM1 esp-aes 256 esp-sha256-hmac
lägestunnel
!
crypto ipsec profil standard
set transform-set TRANSFORM1
set ikev2-profil BeelineIPSec_profile
!
gränssnitt Tunnel1
ip-adress 10.20.1.2 255.255.255.252 –Tunneladress
tunnelkälla GigabitEthernet0/2 – Gränssnitt för internetåtkomst
tunnelläge ipsec ipv4
tunneldestinationsdynamiken
tunnelskydd ipsec profil standard
!
Rutter till klientens privata nätverk tillgängliga via Beeline VPN-koncentrator kan ställas in statiskt.IP-väg 172.16.0.0 255.255.0.0 Tunnel1
IP-väg 192.168.0.0 255.255.255.0 Tunnel1Alternativ för Huawei (ar160/120):
ike lokalt namn <login>
#
acl namn ipsec 3999
regel 1 tillåt ip-källa 10.1.1.0 0.0.0.255 -Kontors lokala nätverk
#
aaa
service-schema IPSEC
ruttuppsättning acl 3999
#
ipsec förslag ipsec
esp autentiseringsalgoritm sha2-256
esp krypteringsalgoritm aes-256
#
Ike förslag standard
krypteringsalgoritm aes-256
dh grupp2
autentiseringsalgoritm sha2-256
autentiseringsmetod för delning
integritetsalgoritm hmac-sha2-256
prf hmac-sha2-256
#
ike peer ipsec
fördelad nyckel enkel <Autentiseringslösenord>
lokal-id-typ fqdn
fjärr-id-typ ip
fjärradress 62.141.99.183 –VPN-hub Beeline
service-schema IPSEC
config-exchange begäran
config-exchange set acceptera
config-exchange set skicka
#
ipsec profil ipsecprof
ike-peer ipsec
förslag ipsec
#
gränssnitt Tunnel0/0/0
ip-adress 10.20.1.2 255.255.255.252 –Tunneladress
tunnelprotokoll ipsec
källa GigabitEthernet0/0/1 – Gränssnitt för internetåtkomst
ipsec profil ipsecprof
#
Rutter till klientens privata nätverk tillgängliga via Beeline VPN-koncentrator kan ställas in statisktip 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
Det resulterande kommunikationsdiagrammet ser ut ungefär så här:
Om klienten inte har några exempel på grundkonfigurationen, då brukar vi hjälpa till med deras bildande och göra dem tillgängliga för alla andra.
Allt som återstår är att ansluta CPE till Internet, pinga till svarsdelen av VPN-tunneln och eventuell värd inuti VPN, och det är det, vi kan anta att anslutningen har gjorts.
I nästa artikel kommer vi att berätta hur vi kombinerade detta schema med IPSec och MultiSIM-redundans med Huawei CPE: vi installerar vår Huawei CPE för kunder, som inte bara kan använda en trådbunden internetkanal, utan också 2 olika SIM-kort, och CPE bygger automatiskt om IPSec-tunneln antingen via trådbundet WAN eller via radio (LTE#1/LTE#2), vilket ger hög feltolerans för den resulterande tjänsten.
Särskilt tack till våra RnD-kollegor för att förbereda den här artikeln (och faktiskt till författarna till dessa tekniska lösningar)!
Källa: will.com