Tere! IN
Alustada tasub sellest, et meil kui sideoperaatoril on oma tohutu MPLS-võrk, mis tavatelefoni klientide jaoks jaguneb kaheks põhisegmendiks – see, mida kasutatakse otse internetti pääsemiseks, ja see, mis on kasutatakse eraldatud võrkude loomiseks – ja just selle MPLS segmendi kaudu liiguvad meie äriklientide jaoks IPVPN (L3 OSI) ja VPLAN (L2 OSI) liiklus.
Tavaliselt toimub kliendiühendus järgmiselt.
Võrgu lähimast kohalolekupunktist (sõlmed MEN, RRL, BSSS, FTTB jne) viiakse kliendi kontorisse juurdepääsuliin ja edasi registreeritakse kanal transpordivõrgu kaudu vastavasse PE-MPLS-i. ruuter, millel me väljastame selle spetsiaalselt VRF-kliendi jaoks loodud seadmesse, võttes arvesse kliendile vajalikku liiklusprofiili (iga pääsupordi jaoks valitakse profiilisildid, mis põhinevad IP-i prioriteetsuse väärtustel 0,1,3,5, XNUMX).
Kui me mingil põhjusel ei saa kliendi jaoks viimast miili täielikult korraldada, näiteks asub kliendi kontor ärikeskuses, kus on eelisjärjekorras mõni teine pakkuja või meil lihtsalt pole oma kohalolekupunkti läheduses, siis varasemad kliendid pidi looma mitu IPVPN-võrku erinevate pakkujate juures (mitte kõige kulutõhusam arhitektuur) või iseseisvalt lahendama probleemid, mis on seotud teie VRF-ile Interneti kaudu juurdepääsu korraldamisega.
Paljud tegid seda IPVPN-i Interneti-lüüsi installides – nad paigaldasid piiriruuteri (riistvara või mõne Linuxi-põhise lahenduse), ühendasid sellega ühe pordiga IPVPN-kanali ja teisega Interneti-kanali, käivitasid sellel oma VPN-serveri ja ühendasid kasutajad oma VPN-lüüsi kaudu. Loomulikult tekitab selline skeem ka koormusi: selline infrastruktuur tuleb välja ehitada ja mis kõige ebamugavam, seda opereerida ja arendada.
Klientide elu hõlbustamiseks installisime tsentraliseeritud VPN-i jaoturi ja korraldasime Interneti-ühenduste toe IPSec-i abil, st nüüd peavad kliendid konfigureerima oma ruuteri, et see töötaks meie VPN-i jaoturiga IPSec-tunneli kaudu mis tahes avaliku Interneti kaudu. , ja vabastame selle kliendi liikluse selle VRF-i.
Kellele vaja läheb
- Neile, kellel on juba suur IPVPN-võrk ja kes vajavad lühikese aja jooksul uusi ühendusi.
- Igaüks, kes soovib mingil põhjusel osa liiklusest avalikust Internetist IPVPN-i üle kanda, kuid on varem kokku puutunud mitme teenusepakkujaga seotud tehniliste piirangutega.
- Neile, kellel on praegu mitu erinevat VPN-võrku erinevate telekommunikatsioonioperaatorite vahel. On kliente, kes on IPVPN-i edukalt korraldanud Beeline'ilt, Megafonilt, Rostelecomilt jne. Selle lihtsamaks muutmiseks võite jääda ainult meie ühe VPN-i juurde, lülitada teiste operaatorite kõik muud kanalid Internetti ja seejärel luua ühendus Beeline IPVPN-iga IPSec-i ja nende operaatorite Interneti kaudu.
- Neile, kellel on juba Internetis IPVPN-võrk.
Kui juurutate kõik koos meiega, saavad kliendid täieõigusliku VPN-i toe, tõsise infrastruktuuri koondamise ja standardseaded, mis töötavad kõigis harjumuspärastes ruuterites (olgu see siis Cisco, isegi Mikrotik, peaasi, et see saaks korralikult toetada). IPSec/IKEv2 standardiseeritud autentimismeetoditega). Muide, IPSeci kohta - praegu toetame seda ainult, kuid plaanime käivitada nii OpenVPN-i kui ka Wireguardi täiemahulise töö, et kliendid ei saaks protokollist sõltuda ning kõike oleks veelgi lihtsam võtta ja meile üle kanda, ning tahame ka hakata ühendama kliente arvutitest ja mobiilseadmetest (OS-i sisseehitatud lahendused, Cisco AnyConnect ja strongSwan jms). Selle lähenemisviisiga saab infrastruktuuri de facto ehitamise ohutult üle anda operaatorile, jättes alles ainult CPE või hosti konfiguratsiooni.
Kuidas ühendusprotsess IPSec-režiimis töötab:
- Klient jätab oma haldurile päringu, milles märgib tunneli jaoks vajaliku ühenduse kiiruse, liiklusprofiili ja IP-aadressi parameetrid (vaikimisi /30 maskiga alamvõrk) ning marsruutimise tüübi (staatiline või BGP). Marsruutide ülekandmiseks kliendi kohtvõrkudesse ühendatud kontoris kasutatakse IPSec-protokolli faasi IKEv2 mehhanisme, kasutades kliendi ruuteri vastavaid sätteid või reklaamitakse neid BGP kaudu MPLS-is kliendi rakenduses määratud privaatsest BGP AS-ist. . Seega juhib klient täielikult teavet kliendivõrkude marsruutide kohta kliendi ruuteri sätete kaudu.
- Vastuseks oma juhilt saab klient raamatupidamisandmeid vormi VRF-i lisamiseks:
- VPN-HUB IP-aadress
- kasutajanimi
- Autentimise parool
- Konfigureerib allpool näiteks kahte põhikonfiguratsioonivalikut:
Valik Cisco jaoks:
krüpto ikev2 võtmehoidja BeelineIPsec_keyring
peer Beeline_VPNHub
aadress 62.141.99.183 - VPN-i jaotur Beeline
pre-shared-key <Autentimise parool>
!
Staatilise marsruutimise valiku puhul saab IKEv2 konfiguratsioonis määrata marsruute Vpn-jaoturi kaudu juurdepääsetavate võrkudeni ja need kuvatakse automaatselt staatiliste marsruutidena CE-marsruutimise tabelis. Neid seadistusi saab teha ka staatiliste marsruutide määramise standardmeetodil (vt allpool).krüpto ikev2 autoriseerimispoliitika FlexClient-author
Marsruut CE-ruuteri taga asuvatesse võrkudesse – CE ja PE vahelise staatilise marsruutimise kohustuslik säte. Teekonna andmete edastamine PE-le toimub automaatselt, kui tunnel tõstetakse IKEv2 interaktsiooni kaudu.
marsruudi komplekt remote ipv4 10.1.1.0 255.255.255.0 -kontori kohtvõrk
!
krüpto ikev2 profiil BeelineIPSec_profile
identiteet kohalik <sisselogimine>
autentimine kohalik eeljagamine
autentimise kaug-eeljagamine
võtmehoidja kohalik BeelineIPsec_keyring
aaa autoriseerimisgrupp psk loend group-author-list FlexClient-author
!
krüpto ikev2 klient flexvpn BeelineIPsec_flex
peer 1 Beeline_VPNHub
kliendiühendus Tunnel1
!
krüpto ipsec transform-set TRANSFORM1 esp-aes 256 esp-sha256-hmac
režiimi tunnel
!
krüpto ipsec profiili vaikeseade
seada teisendus-komplekt TRANSFORM1
määrake ikev2-profiil BeelineIPSec_profile
!
liides Tunnel1
ip-aadress 10.20.1.2 255.255.255.252 – Tunneli aadress
tunneli allikas GigabitEthernet0/2 - Interneti-juurdepääsu liides
tunnelirežiim ipsec ipv4
tunneli sihtkoha dünaamiline
tunneli kaitse ipsec profiili vaikeseade
!
Beeline VPN-i kontsentraatori kaudu juurdepääsetavaid marsruute kliendi privaatvõrkudesse saab seadistada staatiliselt.IP marsruut 172.16.0.0 255.255.0.0 Tunnel1
IP marsruut 192.168.0.0 255.255.255.0 Tunnel1Valik Huawei (ar160/120) jaoks:
nagu kohalik nimi <sisselogimine>
#
acl nimi ipsec 3999
reegel 1 luba ip allikas 10.1.1.0 0.0.0.255 -kontori kohtvõrk
#
aaa
teenindusskeem IPSEC
marsruudi komplekt acl 3999
#
ipsec ettepanek ipsec
esp autentimisalgoritm sha2-256
esp krüpteerimisalgoritm aes-256
#
ike ettepaneku vaikimisi
krüpteerimisalgoritm aes-256
dh rühm2
autentimisalgoritm sha2-256
autentimismeetodi eeljagamine
terviklikkus-algoritm hmac-sha2-256
prf hmac-sha2-256
#
ike peer ipsec
eeljagatud võtme lihtne <Autentimise parool>
kohalik-id-tüüpi fqdn
remote-id-tüüpi ip
kaug-aadress 62.141.99.183 - VPN-i jaotur Beeline
teenindusskeem IPSEC
konfiguratsioonivahetuse taotlus
konfiguratsioonivahetuskomplekt aktsepteerima
konfiguratsioonivahetuskomplekti saatmine
#
ipsec-profiil ipsecprof
ike-peer ipsec
ettepanek ipsec
#
liides Tunnel0/0/0
ip-aadress 10.20.1.2 255.255.255.252 – Tunneli aadress
tunneli protokoll ipsec
allikas GigabitEthernet0/0/1 - Interneti-juurdepääsu liides
ipsec-profiil ipsecprof
#
Beeline VPN-i kontsentraatori kaudu juurdepääsetavaid marsruute kliendi privaatvõrkudesse saab seadistada staatiliseltIP marsruut-staatiline 192.168.0.0 255.255.255.0 Tunnel0/0/0
IP marsruut-staatiline 172.16.0.0 255.255.0.0 Tunnel0/0/0
Saadud suhtlusskeem näeb välja umbes selline:
Kui kliendil puuduvad mõned põhikonfiguratsiooni näidised, siis aitame tavaliselt nende moodustamisel ja teeme need kõigile teistele kättesaadavaks.
Jääb üle vaid ühendada CPE Internetiga, pingida VPN-tunneli vastuseosale ja mis tahes VPN-i sees olevale hostile ning kõik, võime eeldada, et ühendus on loodud.
Järgmises artiklis räägime teile, kuidas kombineerisime selle skeemi IPSeci ja MultiSIM-i koondamisega Huawei CPE abil: installime klientidele oma Huawei CPE, mis saab kasutada mitte ainult traadiga Interneti-kanalit, vaid ka kahte erinevat SIM-kaarti ja CPE-d. ehitab automaatselt ümber IPSec-tunneli kas juhtmega WAN-i või raadio kaudu (LTE#2/LTE#1), realiseerides tulemuseks oleva teenuse kõrge tõrketaluvuse.
Eriline tänu meie RnD kolleegidele selle artikli ettevalmistamise eest (ja tegelikult ka nende tehniliste lahenduste autoritele)!
Allikas: www.habr.com