Hur man kommer åt IPVPN Beeline via IPSec. Del 1

Hej! I i det föregående inlägget Jag har beskrivit hur vår MultiSIM-tjänst fungerar när det gäller reservering och lastbalansering kanaler. Som nämnts ansluter vi kunder till nätverket via VPN, och idag kommer jag att berätta lite mer om VPN och våra möjligheter inom detta område.

Det börjar med att vi som teleoperatör har ett stort MPLS-nät, vilket för kunder med fast telefoni har delats upp i två huvudsegment — det som används för att ansluta till Internet och det som används för att skapa isolerade nät — och det är just genom detta MPLS-segment som IPVPN (L3 OSI) och VPLAN (L2 OSI) trafik passerar för våra företagskunder.

Vanligtvis kopplas kunden på följande sätt.

En anslutningslinje dras till kundens kontor från den närmaste Nätverksnärvaropunkten (Node MEN, PBRL, BSSS, FTTB etc.) och därefter registreras kanalen genom transportnätverket till den motsvarande PE-MPLS-router, där vi kopplar den till en särskilt skapad VRF för kunden med beaktande av den trafikprofil som kunden behöver (profilmärken väljs för varje anslutningsport baserat på värdena ip precedence 0,1,3,5).

Om vi av någon anledning inte kan organisera sista milen för kunden helt och hållet, till exempel om kundens kontor ligger i ett affärscenter där en annan leverantör har prioritet, eller om det helt enkelt inte finns någon närliggande närvaropunkt, så har kunderna tidigare varit tvungna att skapa flera IPVPN-nät hos olika leverantörer (inte den mest kostnadseffektiva arkitekturen) eller själva lösa frågor om att få tillgång till sitt VRF över Internet.

Många gjorde detta genom att installera en IPVPN-internett gateway — de installerade en gränsrouter (hårdvara eller någon lösning baserad på Linux), anslöt en port till IPVPN-kanalen och en annan till Internetkanalen, och körde sin egen VPN-servern och anslöt användare genom sin egen VPN-gateway. Naturligtvis ger en sådan lösning upphov till en del belastningar: en sådan infrastruktur måste man veta hur man bygger och, det mest besvärliga — att driva och utveckla.

För att underlätta livet för våra kunder har vi installerat en centraliserad VPN-hubb och organiserat stöd för anslutningar över internet med IPSec. Det innebär att kunderna nu bara behöver konfigurera sin router för att arbeta med vår VPN-hubb via IPSec-tunneln genom vilken offentlig internet som helst, och vi kommer att släppa trafiken för den kunden i hans VRF.

Vem kan ha nytta av det

• De som redan har ett stort IPVPN-nätverk och har behov av nya anslutningar på kort tid.
• Alla som av olika anledningar vill flytta en del av trafiken från det offentliga internet till IPVPN, men tidigare har stött på tekniska begränsningar relaterade till flera tjänsteleverantörer.
• De som för närvarande har flera olika VPN-nätverk hos olika operatörer. Det finns kunder som framgångsrikt organiserar IPVPN både från Beeline, Megafon och Rostelecom, etc. För att göra det enklare kan man bara hålla sig till vår enhetliga lösning. VPN, alla andra kanaler från andra operatörer kan kopplas till internet, varefter man kan ansluta till Beeline IPVPN via IPSec och internet från dessa operatörer.
• De som redan har ett IPVPN-nätverk ovanpå internet.

Om man rullar ut allt hos oss får kunderna både fullständigt stöd för VPN, seriös infrastrukturreservering och standardinställningar som fungerar på vilken router som helst de är vana vid (oavsett om det är Cisco eller Mikrotik, så länge den kan stödja IPSec/IKEv2 med standardmetoder för autentisering). För övrigt, när det gäller IPSec — just nu stöder vi bara det, men vi planerar att lansera fullt stöd för både OpenVPN och Wireguard, så att kunderna inte behöver vara beroende av protokollet och enklare kan flytta allt till oss, samt att vi vill börja ansluta kunder från datorer och mobila enheter (inbyggda lösningar i operativsystemet, Cisco AnyConnect och strongSwan och liknande). Med denna strategi kan man utan tvekan överlåta infrastrukturen till operatören och bara lämna inställningen av CPE eller värden.

Hur går anslutningsprocessen för IPSec-läget:

1. Kunden lämnar en ansökan till sin manager där de anger den nödvändiga hastigheten för uppkoppling, trafikprofilen och IP-adresseringsparametrarna för tunneln (som standard ett nät med masken /30) och typen av rutten (statisk eller BGP). För att överföra rutter till kundens lokala nätverk i det anslutna kontoret används mekanismer för IKEv2 i fasen av IPSec-protokollet med hjälp av motsvarande inställningar på kundens router, eller annonseras via BGP i MPLS från den privata BGP AS som kunden angivit i sin ansökan. På så sätt kontrollerar kunden helt informationen om rutter i kundens nätverk genom inställningarna på kundens router.
2. Som svar från sin manager får kunden kontouppgifter att inkludera i sin VRF av typen:
   • IP-adress för VPN-HUB
   • Användarnamn
   • Autentiseringslösenord
3. Konfigurera CPE, nedan, för exempel två alternativ för grundkonfiguration:Alternativ för Cisco:
   crypto ikev2 keyring BeelineIPsec_keyring
   peer Beeline_VPNHub
   address 62.141.99.183 –VPN-koncetrator Beeline
   pre-shared-key
   !
   För alternativet med statisk routing kan rutter till nätverk som är tillgängliga via Vpn-hub anges i IKEv2-inställningen och de kommer automatiskt att visas som statiska rutter i CPE:ns routingtabell. Dessa inställningar kan också göras på det vanliga sättet att ange statiska rutter (se nedan).

   crypto ikev2 authorization policy FlexClient-author

   Rutt till nätverk bakom CPE-routern – en obligatorisk inställning vid statisk routing mellan CPE och PE. Överföring av ruttdata till PE sker automatiskt vid uppkoppling av tunneln via IKEv2-interaktion.

   route set remote ipv4 10.1.1.0 255.255.255.0 –Lokalt kontorsnät
   !
   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 –Tunnelens adress
   tunnel source GigabitEthernet0/2 –Internetåtkomstgränssnitt
   tunnel mode ipsec ipv4
   tunnel destination dynamic
   tunnel protection ipsec profile default
   !
   Rutter till kundens privata nätverk som är tillgängliga via VPN-koncetrator Beeline kan anges statiskt.

   ip route 172.16.0.0 255.255.0.0 Tunnel1
   ip route 192.168.0.0 255.255.255.0 Tunnel1

   Alternativ för Huawei (ar160/120):
   ike local-name
   #
   acl name ipsec 3999
   regel 1 tillåter ip-källa 10.1.1.0 0.0.0.255 –Lokalt kontorsnät
   #
   aaa
   tjänste-schema IPSEC
   route set acl 3999
   #
   ipsec förslag ipsec
   esp autentiserings-algoritm sha2-256
   esp krypterings-algoritm aes-256
   #
   ike-förslag standard
   krypterings-algoritm aes-256
   dh grupp2
   autentiserings-algoritm sha2-256
   autentiseringsmetod förhandsdelad
   integritets-algoritm hmac-sha2-256
   prf hmac-sha2-256
   #
   ike-partner ipsec
   förhandsdelad nyckel enkel
   lokal-id-typ fqdn
   remot-id-typ ip
   remote-address 62.141.99.183 –VPN-koncetrator Beeline
   tjänste-schema IPSEC
   config-exchange begäran
   config-exchange set acceptera
   config-exchange set skicka
   #
   ipsec-profil ipsecprof
   ike-partner ipsec
   förslag ipsec
   #
   gränssnitt Tunnel0/0/0
   ip address 10.20.1.2 255.255.255.252 –Tunnelens adress
   tunnel-protokoll ipsec
   källa GigabitEthernet0/0/1 –Internetåtkomstgränssnitt
   ipsec-profil ipsecprof
   #
   Rutter till kundens privata nätverk, tillgängliga via Beeline VPN-koncentrator, kan ställas in statiskt

   ip 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

Den resulterande kommunikationsschemat ser ungefär ut så här:

Om kunden inte har några exempel på grundläggande konfiguration, hjälper vi vanligtvis till att skapa dem och gör dem tillgängliga för alla andra.

Det återstår att ansluta CPE till internet, göra ping till den svarande delen av VPN-tunneln och till någon värd inom VPN, och allt, man kan säga att anslutningen etablerades.

I nästa artikel berättar vi hur vi kombinerade detta schema med IPSec och MultiSIM-redundans med hjälp av CPE Huawei: vi installerar våra kunders CPE Huawei, som kan använda inte bara en trådbunden internetkanal, utan också 2 olika SIM-kort, och CPE själva rekonfigurerar IPSec-tunneln antingen via trådad WAN eller via radio (LTE#1/LTE#2), vilket möjliggör hög redundans för den slutliga tjänsten.

Ett särskilt tack för att förbereda denna artikel (och faktiskt till författarna av dessa tekniska lösningar) till kollegorna i vårt RnD!

Källa: habr.com