Hallo! I Jeg beskrev delvis arbeidet til MultiSIM-tjenesten vår и kanaler. Som nevnt kobler vi klienter til nettverket via VPN, og i dag skal jeg fortelle litt mer om VPN og våre muligheter i denne delen.
Det er verdt å starte med at vi som teleoperatør har vårt eget enorme MPLS-nettverk, som for fastnettkunder er delt inn i to hovedsegmenter - det som brukes direkte for å få tilgang til Internett, og det som er brukes til å lage isolerte nettverk — og det er gjennom dette MPLS-segmentet at IPVPN (L3 OSI) og VPLAN (L2 OSI) trafikk flyter for våre bedriftskunder.
Vanligvis skjer en klienttilkobling som følger.
En tilgangslinje legges til klientens kontor fra nærmeste tilstedeværelse i nettverket (node MEN, RRL, BSSS, FTTB, etc.) og videre registreres kanalen gjennom transportnettet til den tilsvarende PE-MPLS ruter, som vi sender den ut til en spesielt opprettet for VRF-klienten, under hensyntagen til trafikkprofilen som klienten trenger (profiletiketter velges for hver tilgangsport, basert på ip-prioritetsverdiene 0,1,3,5, XNUMX).
Hvis vi av en eller annen grunn ikke fullt ut kan organisere den siste milen for kunden, for eksempel kundens kontor ligger i et forretningssenter, der en annen leverandør er en prioritet, eller vi rett og slett ikke har vårt tilstedeværelse i nærheten, så tidligere kunder måtte opprette flere IPVPN-nettverk hos forskjellige leverandører (ikke den mest kostnadseffektive arkitekturen) eller uavhengig løse problemer med å organisere tilgang til VRF-en din over Internett.
Mange gjorde dette ved å installere en IPVPN Internett-gateway - de installerte en grenseruter (maskinvare eller en Linux-basert løsning), koblet en IPVPN-kanal til den med en port og en Internett-kanal med den andre, startet VPN-serveren deres på den og koblet til. brukere gjennom sin egen VPN-gateway. Naturligvis skaper en slik ordning også byrder: slik infrastruktur må bygges og, mest upraktisk, driftes og utvikles.
For å gjøre livet enklere for kundene våre, installerte vi en sentralisert VPN-hub og organiserte støtte for tilkoblinger over Internett ved hjelp av IPSec, det vil si at nå trenger kundene bare å konfigurere ruteren til å fungere med VPN-huben vår via en IPSec-tunnel over et hvilket som helst offentlig Internett , og vi La oss frigi denne klientens trafikk til VRF.
Hvem vil trenge
- For de som allerede har et stort IPVPN-nettverk og trenger nye tilkoblinger på kort tid.
- Alle som av en eller annen grunn ønsker å overføre deler av trafikken fra det offentlige Internett til IPVPN, men tidligere har vært borti tekniske begrensninger knyttet til flere tjenesteleverandører.
- For de som for tiden har flere forskjellige VPN-nettverk på tvers av forskjellige teleoperatører. Det er kunder som har vellykket organisert IPVPN fra Beeline, Megafon, Rostelecom, etc. For å gjøre det enklere, kan du bare bo på vår enkelt VPN, bytte alle andre kanaler til andre operatører til Internett, og deretter koble til Beeline IPVPN via IPSec og Internett fra disse operatørene.
- For de som allerede har et IPVPN-nettverk lagt over Internett.
Hvis du distribuerer alt hos oss, mottar klienter fullverdig VPN-støtte, seriøs infrastrukturredundans og standardinnstillinger som vil fungere på alle rutere de er vant til (det være seg Cisco, til og med Mikrotik, det viktigste er at den kan støtte riktig IPSec/IKEv2 med standardiserte autentiseringsmetoder). Forresten, om IPSec - akkurat nå støtter vi det bare, men vi planlegger å lansere fullverdig drift av både OpenVPN og Wireguard, slik at klienter ikke kan stole på protokollen og det er enda enklere å ta og overføre alt til oss, og vi ønsker også å begynne å koble klienter fra datamaskiner og mobile enheter (løsninger innebygd i OS, Cisco AnyConnect og strongSwan og lignende). Med denne tilnærmingen kan de facto-konstruksjonen av infrastrukturen trygt overleveres til operatøren, og bare konfigurasjonen av CPE eller verten blir igjen.
Hvordan fungerer tilkoblingsprosessen for IPSec-modus:
- Klienten overlater en forespørsel til sin leder der han angir nødvendig tilkoblingshastighet, trafikkprofil og IP-adresseringsparametere for tunnelen (som standard et subnett med /30-maske) og type ruting (statisk eller BGP). For å overføre ruter til klientens lokale nettverk i det tilkoblede kontoret, brukes IKEv2-mekanismene til IPSec-protokollfasen ved å bruke de riktige innstillingene på klientruteren, eller de annonseres via BGP i MPLS fra den private BGP AS spesifisert i klientens applikasjon . Dermed er informasjon om rutene til klientnettverk fullstendig kontrollert av klienten gjennom innstillingene til klientruteren.
- Som svar fra sin leder mottar klienten regnskapsdata for inkludering i sin VRF av skjemaet:
- VPN-HUB IP-adresse
- Logg inn
- Autentiseringspassord
- Konfigurerer CPE, nedenfor, for eksempel to grunnleggende konfigurasjonsalternativer:
Alternativ for Cisco:
krypto ikev2 nøkkelring BeelineIPsec_nøkkelring
peer Beeline_VPNHub
adresse 62.141.99.183 –VPN-hub Beeline
forhåndsdelt nøkkel <Autentiseringspassord>
!
For det statiske rutingsalternativet kan ruter til nettverk tilgjengelig via Vpn-hub spesifiseres i IKEv2-konfigurasjonen, og de vil automatisk vises som statiske ruter i CE-rutingstabellen. Disse innstillingene kan også gjøres ved å bruke standardmetoden for å sette statiske ruter (se nedenfor).crypto ikev2 autorisasjonspolicy FlexClient-forfatter
Rute til nettverk bak CE-ruteren – en obligatorisk innstilling for statisk ruting mellom CE og PE. Overføringen av rutedata til PE utføres automatisk når tunnelen heves gjennom IKEv2-interaksjon.
rutesett ekstern ipv4 10.1.1.0 255.255.255.0 – Lokalt kontornettverk
!
krypto ikev2 profil BeelineIPSec_profile
identitet lokal <pålogging>
autentisering lokal forhåndsdeling
autentisering ekstern forhåndsdeling
nøkkelring lokal BeelineIPsec_nøkkelring
aaa autorisasjonsgruppe psk liste gruppe-forfatter-liste FlexClient-forfatter
!
krypto ikev2 klient flexvpn BeelineIPsec_flex
peer 1 Beeline_VPNHub
klienttilkobling Tunnel1
!
crypto ipsec transform-sett TRANSFORM1 esp-aes 256 esp-sha256-hmac
modus tunnel
!
crypto ipsec profil standard
sett transform-sett TRANSFORM1
sett ikev2-profil BeelineIPSec_profile
!
grensesnitt Tunnel1
ip-adresse 10.20.1.2 255.255.255.252 – Tunneladresse
tunnelkilde GigabitEthernet0/2 – Internett-tilgangsgrensesnitt
tunnelmodus ipsec ipv4
tunneldestinasjonsdynamikk
tunnelbeskyttelse ipsec profil standard
!
Ruter til klientens private nettverk tilgjengelig gjennom Beeline VPN-konsentratoren kan stilles statisk.ip-rute 172.16.0.0 255.255.0.0 Tunnel1
ip-rute 192.168.0.0 255.255.255.0 Tunnel1Alternativ for Huawei (ar160/120):
ike lokalt navn <pålogging>
#
acl navn ipsec 3999
regel 1 tillat ip-kilde 10.1.1.0 0.0.0.255 – Lokalt kontornettverk
#
aaa
service-ordningen IPSEC
rutesett acl 3999
#
ipsec-forslag ipsec
esp autentiseringsalgoritme sha2-256
esp krypteringsalgoritme aes-256
#
ike forslag standard
krypteringsalgoritme aes-256
dh gruppe2
autentiseringsalgoritme sha2-256
autentiseringsmetode forhåndsdeling
integritetsalgoritme hmac-sha2-256
prf hmac-sha2-256
#
ike peer ipsec
enkel forhåndsdelt nøkkel <Autentiseringspassord>
lokal-id-type fqdn
ekstern-id-type ip
ekstern adresse 62.141.99.183 –VPN-hub Beeline
service-ordningen IPSEC
config-exchange forespørsel
config-exchange sett godta
config-exchange sett send
#
ipsec-profil ipsecprof
ike-peer ipsec
forslag ipsec
#
grensesnitt Tunnel0/0/0
ip-adresse 10.20.1.2 255.255.255.252 – Tunneladresse
tunnel-protokoll ipsec
kilde GigabitEthernet0/0/1 – Internett-tilgangsgrensesnitt
ipsec-profil ipsecprof
#
Ruter til klientens private nettverk tilgjengelig gjennom Beeline VPN-konsentratoren kan settes 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 kommunikasjonsdiagrammet ser omtrent slik ut:
Hvis klienten ikke har noen eksempler på den grunnleggende konfigurasjonen, hjelper vi vanligvis med dannelsen og gjør dem tilgjengelige for alle andre.
Alt som gjenstår er å koble CPE til Internett, ping til responsdelen av VPN-tunnelen og en hvilken som helst vert inne i VPN, og det er det, vi kan anta at forbindelsen er opprettet.
I den neste artikkelen vil vi fortelle deg hvordan vi kombinerte denne ordningen med IPSec og MultiSIM Redundancy ved hjelp av Huawei CPE: vi installerer vår Huawei CPE for klienter, som ikke bare kan bruke en kablet Internett-kanal, men også 2 forskjellige SIM-kort, og CPE bygger automatisk opp IPSec-tunnelen enten via kablet WAN eller via radio (LTE#1/LTE#2), og realiserer høy feiltoleranse for den resulterende tjenesten.
Spesiell takk til våre RnD-kolleger for å ha utarbeidet denne artikkelen (og faktisk til forfatterne av disse tekniske løsningene)!
Kilde: www.habr.com