Hej! I i det tidligere indlæg beskrev jeg, hvordan vores MultiSIM-service fungerer i forhold til reservationssystemet og lastbalancering af kanaler. Som nævnt tidligere tilslutter vi kunder til netværket via VPN, og i dag vil jeg fortælle lidt mere om VPN og vores muligheder på dette område.
Det skal bemærkes, at vi som teleselskab har vores eget store MPLS-netværk, som for kunder med fast forbindelse er opdelt i to hovedsegmenter - det, der bruges direkte til adgang til internettet, og det, der bruges til at skabe isolerede netværk - og det er gennem dette MPLS-segment, at IPVPN (L3 OSI) og VPLAN (L2 OSI) trafik til vores erhvervskunder går.
Normalt sker kundens tilslutning som følger.
En adgangslinje føres til kundens kontor fra den nærmeste Point of Presence (PoP) i netværket (MEN-noden, P2P, BSSS, FTTB osv.), og derfra registreres kanalen på transportnetværket til den tilsvarende RE-MPLS-router, hvor vi tilslutter den til en specielt oprettet VRF for kunden under hensyntagen til trafikprofilen, som kunden har brug for (profilmærker vælges for hver adgangsport baseret på værdierne ip precedence 0, 1, 3, 5).
Hvis vi af en eller anden grund ikke kan organisere den sidste mil fuldt ud for kunden, for eksempel hvis kundens kontor ligger i et erhvervscenter, hvor en anden udbyder har prioritet, eller hvis der slet ikke er en PoP i nærheden, så måtte kunderne tidligere oprette flere IPVPN-netværk hos forskellige udbydere (ikke den mest omkostningseffektive arkitektur) eller selv løse spørgsmålene vedrørende adgangen til deres VRF over internettet.
Mange gjorde dette ved at oprette en IPVPN-internetgateway - de satte en grænsenode (hardware eller en Linux-baseret løsning) op, tilsluttede IPVPN-kanalen til den med én port og internetkanalen med en anden, og kørte deres VPN-server og tilsluttede brugerne gennem deres egen VPN-gateway. Naturligvis medfører sådan en ordning også byrder: denne infrastruktur skal man kunne opbygge, og det, der er mest besværligt - vedligeholde og udvikle.
For at gøre livet lettere for vores kunder har vi etableret et centralt VPN-hub og organiseret understøttelse af forbindelser over internettet ved hjælp af IPSec. Det vil sige, at kunderne kun skal konfigurere deres router til at arbejde med vores VPN-hub via IPSec-tunnel over ethvert offentligt internet, hvorefter vi vil frigive trafikken for denne kunde i hans VRF.
Hvem vil have gavn af det
- Dem, der allerede har et stort IPVPN-netværk og har brug for nye forbindelser på kort tid.
- Alle, der af en eller anden grund ønsker at flytte en del af trafikken fra det offentlige internet til IPVPN, men tidligere har stået over for tekniske begrænsninger fra flere tjenesteudbydere.
- Dem, der i øjeblikket har flere adskilte VPN-netværk hos forskellige teleoperatører. Der er kunder, der har succesfuldt organiseret IPVPN både fra Beeline, MegaFon og Rostelecom osv. For at gøre det lettere kan de vælge kun vores enkle løsning, VPN, mens alle andre kanaler fra andre operatører skifter til internettet, hvorefter de kan oprette forbindelse til Beelines IPVPN via IPSec og internet fra disse operatører.
- Dem, der allerede har et IPVPN-netværk oven på internettet.
Hvis de implementerer alt hos os, får kunderne både fuld support til VPN, betydelig infrastrukturreservasjon og standardindstillinger, der fungerer på enhver kendt router (lige meget om det er Cisco eller Mikrotik, blot de kan understøtte IPSec/IKEv2 med standardiserede autentifikationsmetoder). For øvrigt understøtter vi i øjeblikket kun IPSec, men planlægger at lancere fuld funktionalitet for både OpenVPN og Wireguard, så kunderne ikke er afhængige af en protokol, og det bliver endnu lettere at flytte alt til os. Vi ønsker også at begynde at tilslutte kunder fra computere og mobile enheder (indbyggede løsninger i OS, Cisco AnyConnect og strongSwan m.fl.). Med denne tilgang kan vi trygt overlade opbygningen af infrastrukturen til operatøren og kun efterlade konfigurationen af CPE eller værten.
Hvordan foregår tilslutningsprocessen for IPSec-tilstand:
- Klienten sender en ansøgning til sin manager, hvor han angiver den nødvendige forbindelseshastighed, trafikprofil og IP-adresseringsparametre for tunnelen (som standard et subnet med maske /30) samt type routing (statisk eller BGP). For at overføre ruter til de lokale netværk i det tilsluttede kontor anvendes IKEv2-fasen af IPSec-protokollen med de relevante indstillinger på klientens router, eller de annonceres via BGP i MPLS fra den private BGP AS, som kunden angivet i ansøgningen. På den måde styres informationen om kundens netværksruter helt af klienten gennem indstillingerne på klientens router.
- Som svar fra sin manager modtager klienten kontooplysninger til at inkludere i sin VRF i følgende format:
- IP-adresse VPN-HUB
- Login
- Godkendelsespassword
- Konfigurerer CSR, nedenfor er to eksempler på grundlæggende konfiguration:Mulighed for Cisco:
crypto ikev2 keyring BeelineIPsec_keyring
peer Beeline_VPNHub
address 62.141.99.183 – VPN-hub fra Beeline
pre-shared-key
!
For muligheden med statisk routing kan ruterne til netværk tilgængelige gennem VPN-hub’en defineres i IKEv2-indstillingen, og de vil automatisk dukke op som statiske ruter i CSR’s routingtabel. Disse indstillinger kan også laves på den standard måde ved at angive statiske ruter (se nedenfor).crypto ikev2 authorization policy FlexClient-author
Ruten til netværk bag CSR-ruteren er en obligatorisk indstilling ved statisk routing mellem CSR og PE. Overførsel af ruter til PE sker automatisk ved oprettelse af tunnelen via IKEv2-interaktionen.
route set remote ipv4 10.1.1.0 255.255.255.0 – Kontorens lokale netværk
!
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 adresse
tunnel source GigabitEthernet0/2 – Internet-adgangsinterface
tunnel mode ipsec ipv4
tunnel destination dynamic
tunnel protection ipsec profile default
!
Ruter til kundens private netværk, der er tilgængelige gennem VPN-hub fra Beeline, kan angives statisk.ip route 172.16.0.0 255.255.0.0 Tunnel1
ip route 192.168.0.0 255.255.255.0 Tunnel1Mulighed for Huawei (ar160/120):
ike local-name
#
acl name ipsec 3999
regel 1 tillad ip kilde 10.1.1.0 0.0.0.255 – Kontorens lokale netværk
#
aaa
service-scheme IPSEC
rute sæt acl 3999
#
ipsec forslag ipsec
esp autentificerings-algoritme sha2-256
esp krypterings-algoritme aes-256
#
ike forslag standard
krypterings-algoritme aes-256
dh gruppe2
autentificerings-algoritme sha2-256
autentificeringsmetode pre-share
integritets-algoritme hmac-sha2-256
prf hmac-sha2-256
#
ike peer ipsec
foruddelte nøgle simple
lokal-id-type fqdn
fjernt-id-type ip
fjernt-adresse 62.141.99.183 – VPN-hub fra Beeline
service-scheme IPSEC
config-exchange anmodning
config-exchange sæt accept
config-exchange sæt send
#
ipsec profil ipsecprof
ike-peer ipsec
forslag ipsec
#
interface Tunnel0/0/0
ip address 10.20.1.2 255.255.255.252 – Tunnelens adresse
tunnel-protokol ipsec
kilde GigabitEthernet0/0/1 – Internet-adgangsinterface
ipsec profil ipsecprof
#
Ruter til kundernes private netværk, tilgængelige via Beeline VPN-koncernen, kan angives statiskip rute-statiske 192.168.0.0 255.255.255.0 Tunnel0/0/0
ip rute-statiske 172.16.0.0 255.255.0.0 Tunnel0/0/0
Den resulterende kommunikationsordning ser omtrent sådan ud:
Hvis der ikke er nogen eksempler på grundkonfiguration tilgængelige for kunden, hjælper vi normalt med at udarbejde dem og gør dem tilgængelige for alle andre.
Det er tilbage at forbinde CPE til internettet, lave ping til den modsatte del af VPN-tunnelen og en hvilken som helst vært inden for VPN, og så kan man betragte forbindelsen som etableret.
I den næste artikel vil vi vise, hvordan vi kombinerede dette skema med IPSec og MultiSIM redundans ved hjælp af CPE Huawei: vi installerer vores CPE Huawei hos kunderne, som kan bruge ikke kun en kablet internetforbindelse, men også 2 forskellige SIM-kort, og CPE genopbygger automatisk IPSec-tunnelen enten via kablet WAN eller via radio (LTE#1/LTE#2) for at realisere høj tilgængelighed af den endelige service.
En særlig tak til forberedelsen af denne artikel (og til forfatterne af disse tekniske løsninger) til kollegerne fra vores RnD!
Kilde: habr.com
