Hej! I Jeg beskrev delvist arbejdet med vores MultiSIM-tjeneste и kanaler. Som nævnt forbinder vi klienter til netværket via VPN, og i dag vil jeg fortælle lidt mere om VPN og vores muligheder i denne del.
Det er værd at starte med, at vi som teleoperatør har vores eget enorme MPLS-netværk, som for fastnetkunder er opdelt i to hovedsegmenter - det, der bruges direkte til at få adgang til internettet, og det, der er bruges til at skabe isolerede netværk — og det er gennem dette MPLS-segment, at IPVPN (L3 OSI) og VPLAN (L2 OSI) trafik flyder for vores virksomhedskunder.
Typisk sker en klientforbindelse som følger.
En adgangslinje lægges til kundens kontor fra det nærmeste tilstedeværelse på netværket (node MEN, RRL, BSSS, FTTB osv.), og yderligere registreres kanalen gennem transportnetværket til den tilsvarende PE-MPLS router, hvorpå vi udsender den til en specielt oprettet til VRF-klienten, under hensyntagen til den trafikprofil, som klienten har brug for (profiletiketter vælges for hver adgangsport, baseret på ip-præcedensværdierne 0,1,3,5, XNUMX).
Hvis vi af en eller anden grund ikke fuldt ud kan organisere den sidste mil for kunden, f.eks. hvis kundens kontor er placeret i et forretningscenter, hvor en anden udbyder er en prioritet, eller vi simpelthen ikke har vores tilstedeværelse i nærheden, så er tidligere kunder skulle oprette flere IPVPN-netværk hos forskellige udbydere (ikke den mest omkostningseffektive arkitektur) eller selvstændigt løse problemer med at organisere adgangen til din VRF over internettet.
Mange gjorde dette ved at installere en IPVPN internetgateway - de installerede en grænserouter (hardware eller en eller anden Linux-baseret løsning), tilsluttede en IPVPN-kanal til den med den ene port og en internetkanal med den anden, startede deres VPN-server på den og tilsluttede brugere gennem deres egen VPN-gateway. Naturligvis skaber en sådan ordning også byrder: en sådan infrastruktur skal bygges og, mest ubelejligt, drives og udvikles.
For at gøre livet lettere for vores kunder installerede vi en centraliseret VPN-hub og organiserede support til forbindelser over internettet ved hjælp af IPSec, det vil sige, at kunder nu kun behøver at konfigurere deres router til at arbejde med vores VPN-hub via en IPSec-tunnel over ethvert offentligt internet , og vi Lad os frigive denne klients trafik til dens VRF.
Hvem skal bruge
- For dem, der allerede har et stort IPVPN-netværk og har brug for nye forbindelser på kort tid.
- Enhver, der af en eller anden grund ønsker at overføre en del af trafikken fra det offentlige internet til IPVPN, men tidligere er stødt på tekniske begrænsninger forbundet med flere tjenesteudbydere.
- For dem, der i øjeblikket har flere forskellige VPN-netværk på tværs af forskellige teleoperatører. Der er kunder, der med succes har organiseret IPVPN fra Beeline, Megafon, Rostelecom osv. For at gøre det nemmere kan du kun blive på vores enkelt VPN, skifte alle andre kanaler fra andre operatører til internettet og derefter oprette forbindelse til Beeline IPVPN via IPSec og internettet fra disse operatører.
- For dem, der allerede har et IPVPN-netværk overlejret på internettet.
Hvis du implementerer alt hos os, modtager klienter fuldgyldig VPN-understøttelse, seriøs infrastrukturredundans og standardindstillinger, der fungerer på enhver router, de er vant til (det være sig Cisco, selv Mikrotik, det vigtigste er, at det kan understøtte korrekt IPSec/IKEv2 med standardiserede godkendelsesmetoder). Forresten, om IPSec - lige nu understøtter vi det kun, men vi planlægger at lancere fuldgyldig drift af både OpenVPN og Wireguard, så klienter ikke kan stole på protokollen, og det er endnu nemmere at tage og overføre alt til os, og vi vil også begynde at forbinde klienter fra computere og mobile enheder (løsninger indbygget i OS, Cisco AnyConnect og strongSwan og lignende). Med denne tilgang kan de facto-konstruktionen af infrastrukturen sikkert overdrages til operatøren, så kun konfigurationen af CPE'en eller værten er tilbage.
Hvordan fungerer forbindelsesprocessen for IPSec-tilstand:
- Klienten efterlader en anmodning til sin leder, hvori han angiver den nødvendige forbindelseshastighed, trafikprofil og IP-adresseringsparametre for tunnelen (som standard et undernet med en /30-maske) og typen af routing (statisk eller BGP). For at overføre ruter til klientens lokale netværk i det tilsluttede kontor, bruges IKEv2-mekanismerne i IPSec-protokolfasen ved at bruge de relevante indstillinger på klientrouteren, eller de annonceres via BGP i MPLS fra den private BGP AS specificeret i klientens applikation . Information om ruterne for klientnetværk er således fuldstændig kontrolleret af klienten gennem indstillingerne af klientrouteren.
- Som svar fra sin leder modtager klienten regnskabsdata til medtagelse i sin VRF af formularen:
- VPN-HUB IP-adresse
- Login
- Godkendelsesadgangskode
- Konfigurerer CPE, herunder, for eksempel to grundlæggende konfigurationsmuligheder:
Mulighed for Cisco:
krypto ikev2 nøglering BeelineIPsec_nøglering
peer Beeline_VPNHub
adresse 62.141.99.183 –VPN-hub Beeline
foruddelt nøgle <godkendelsesadgangskode>
!
For den statiske routing-indstilling kan ruter til netværk, der er tilgængelige via Vpn-hubben, specificeres i IKEv2-konfigurationen, og de vises automatisk som statiske ruter i CE-routingtabellen. Disse indstillinger kan også foretages ved hjælp af standardmetoden til indstilling af statiske ruter (se nedenfor).crypto ikev2 autorisationspolitik FlexClient-forfatter
Rute til netværk bag CE-routeren – en obligatorisk indstilling for statisk routing mellem CE og PE. Overførslen af rutedata til PE udføres automatisk, når tunnelen hæves gennem IKEv2-interaktion.
rutesæt fjernbetjening ipv4 10.1.1.0 255.255.255.0 – Kontors lokale netværk
!
krypto ikev2 profil BeelineIPSec_profile
identitet lokal <login>
autentificering lokal pre-share
autentificering fjern foruddeling
nøglering lokal BeelineIPsec_nøglering
aaa autorisationsgruppe psk liste gruppe-forfatter-liste FlexClient-forfatter
!
krypto ikev2 klient flexvpn BeelineIPsec_flex
peer 1 Beeline_VPNHub
klientforbindelse Tunnel1
!
crypto ipsec transform-sæt TRANSFORM1 esp-aes 256 esp-sha256-hmac
mode tunnel
!
crypto ipsec profil standard
sæt transform-sæt TRANSFORM1
sæt ikev2-profil BeelineIPSec_profile
!
grænseflade Tunnel1
ip-adresse 10.20.1.2 255.255.255.252 – Tunneladresse
tunnelkilde GigabitEthernet0/2 -Internetadgang interface
tunneltilstand ipsec ipv4
tunneldestinationsdynamik
tunnelbeskyttelse ipsec profil standard
!
Ruter til klientens private netværk, der er tilgængelige via Beeline VPN-koncentratoren, kan indstilles statisk.ip-rute 172.16.0.0 255.255.0.0 Tunnel1
ip-rute 192.168.0.0 255.255.255.0 Tunnel1Mulighed for Huawei (ar160/120):
ike lokalt navn <login>
#
acl navn ipsec 3999
regel 1 tillad ip-kilde 10.1.1.0 0.0.0.255 – Kontors lokale netværk
#
aaa
service-ordningen IPSEC
rutesæt acl 3999
#
ipsec forslag ipsec
esp authentication-algoritme sha2-256
esp krypteringsalgoritme aes-256
#
ike forslag standard
krypteringsalgoritme aes-256
dh gruppe 2
autentificeringsalgoritme sha2-256
autentificeringsmetode før deling
integritetsalgoritme hmac-sha2-256
prf hmac-sha2-256
#
ike peer ipsec
pre-shared-key simpel <godkendelsesadgangskode>
lokal-id-type fqdn
remote-id-type ip
fjernadresse 62.141.99.183 –VPN-hub Beeline
service-ordningen IPSEC
config-exchange anmodning
config-exchange sæt accept
config-exchange sæt send
#
ipsec profil ipsecprof
ike-peer ipsec
forslag ipsec
#
grænseflade Tunnel0/0/0
ip-adresse 10.20.1.2 255.255.255.252 – Tunneladresse
tunnel-protokol ipsec
kilde GigabitEthernet0/0/1 -Internetadgang interface
ipsec profil ipsecprof
#
Ruter til klientens private netværk, der er tilgængelige via Beeline VPN-koncentratoren, kan indstilles statiskip-rute-statisk 192.168.0.0 255.255.255.0 Tunnel0/0/0
ip-rute-statisk 172.16.0.0 255.255.0.0 Tunnel0/0/0
Det resulterende kommunikationsdiagram ser nogenlunde sådan ud:
Hvis klienten ikke har nogle eksempler på den grundlæggende konfiguration, så hjælper vi som regel med deres dannelse og gør dem tilgængelige for alle andre.
Det eneste, der er tilbage, er at forbinde CPE'en til internettet, ping til svardelen af VPN-tunnelen og enhver vært inde i VPN'en, og det er det, vi kan antage, at forbindelsen er blevet oprettet.
I den næste artikel vil vi fortælle dig, hvordan vi kombinerede denne ordning med IPSec og MultiSIM Redundancy ved hjælp af Huawei CPE: vi installerer vores Huawei CPE til klienter, som ikke kun kan bruge en kablet internetkanal, men også 2 forskellige SIM-kort og CPE genopbygger automatisk IPSec-tunnelen enten via kablet WAN eller via radio (LTE#1/LTE#2), hvilket realiserer høj fejltolerance for den resulterende tjeneste.
Særlig tak til vores RnD-kolleger for at forberede denne artikel (og faktisk til forfatterne af disse tekniske løsninger)!
Kilde: www.habr.com