Kuidas pääseda IPVPN Bileini kaudu IPSeciga. Osa 1

Tere! V eelnevas postituses kirjeldasin meie MultiSIM teenuse toimimist osas reserveerimine ja tasakaalustamine kanalid. Nagu varem mainitud, ühendame kliente võrku VPN-i kaudu ja täna räägin natuke rohkem VPN-ist ja meie võimalustest selle valdkonnas.

Alustuseks tuleb märkida, et meil, kui sideoperandil, on oma suur MPLS-võrk, mis on fikseeritud side klientide jaoks jagatud kaheks peamiseks segmendiks — see, mida kasutatakse otse Internetti pääsemiseks, ja see, mida kasutatakse isoleeritud võrkude loomiseks — ja just selle MPLS-segmendi kaudu liigub IPVPN (L3 OSI) ja VPLAN (L2 OSI) liiklus meie äriklientide jaoks.

Tavaliselt toimub kliendi ühendamine järgmisel viisil.

Kliendi bürood ühendatakse lähima äriühingu tarnekeskuse (MEN, PPL, BSS, FTTB jne) kaudu juurdepääsuliiniga, mille kaudu kanal suunatakse vastava RE-MPLS ruuteri kaudu transiidivõrku, kust me selle suuname kliendi jaoks loodud VRF-i, arvestades liiklusprofiili, mis on kliendile vajalik (profiili sildid valitakse iga juurpordi jaoks, tuginedes ip precedence väärtustele 0, 1, 3, 5).

Kui mingil põhjusel ei suuda me kliendile viimast miili korralikult korraldada, näiteks kui kliendi büroo asub ärikeskuses, kus eelistatakse teist teenusepakkujat, või kui meie juurdepääsupunkti ei ole läheduses, pidi klient varem looma mitu IPVPN-võrku erinevate teenusepakkujatega (mis ei ole hindade järgi kõige kasulikum arhitektuur) või iseseisvalt lahendama probleemid juurdepääs korraldamisega oma VRF-ile Interneti-võrgus.

Paljud tegid seda IPVPN-interneti värava paigaldamisega — paigaldasid piiri ruuteri (riistvara või mingisuguse Linuxi-põhise lahenduse), ühendasid ühe pordi IPVPN-kanaliga ja teise Interneti-kanaliga, ning käivitasid sellel oma VPN-serveri ja ütles, et nad jätavad kasutajad ümber omaenda VPN-silla. Loomulikult loob selline lahendus ka laenguid: sarnast infrastruktuuri tuleb osata üles ehitada ja mis kõige ebamugavam — kasutada ja arendada.

Elu meie klientidele lihtsustamiseks oleme seadnud üles centraliseeritud VPN-hubi ja korraldanud IPSeci kaudu Interneti-ühenduse toe, mis tähendab, et nüüd piisab klientidel ainult oma ruuteri seadistamisest meie VPN-hubi tööks IPSec-tunneli kaudu igasuguse avaliku Interneti kaudu, ja suuname selle kliendi liikluse tema VRF-i.

Kellele see sobib

• Neile, kellel on juba suur IPVPN-võrk ja kes vajavad uute ühenduste loomist kiirelt.
• Kõigile neile, kes soovivad mingil põhjusel suunata osa liiklust avalikust Internetist IPVPN-i, kuid on varem kokku puutunud tehniliste piirangutega, mis on seotud mitme teenusepakkujaga.
• Neile, kellel on hetkel mitu eraldiseisvat VPN-võrku erinevatelt teenusepakkujatelt. On kliente, kellel on edukalt korraldatud IPVPN nii Beeline'i, Megaфон'i kui ka Rostelecom'i jms kaudu. Lihtsamaks muutmiseks võib jääda ainult meie ühise lahenduse juurde. VPN, kõik muud operaatorite kanalid tuleb suunata internetti, mille järel saab ühendada Beline IPVPN-i IPSec-i ja nende operaatorite internetti.
• Neile, kellel on juba IPVPN-võrk, mis on kattuvad Internetiga.

Kui kõik meie juures üles seada, saavad kliendid täielikku VPN-i tuge, tõsist infrastruktuuri reserveerimist ning standardseid seadistusi, mis töötavad igas tuttavas ruuteris (olgu see siis Cisco või Mikrotik, peamine, et see toetaks IPSec/IKEv2 standardiseeritud autentimismeetodeid). Muide, mis puutub IPSec-i, siis praegu toetame me ainult seda, kuid plaanime avada ka OpenVPN-i ja Wireguardi täisfunktsionaalsuse, et kliendid ei sõltuks protokollist ja saaksid veelgi lihtsamalt kõik meie juurde viia. Samuti soovime hakata ühendama kliente arvutitest ja mobiilseadmetest (operatsioonisüsteemide integreeritud lahendusi, Cisco AnyConnecti ja strongSwan'i ning sarnaseid). Sellise lähenemisega võib de facto infrastruktuuri usaldada operaatorile, jättes alles vaid SRV või hosti seadistamise.

Kuidas toimub ühendamise protsess IPSec-režiimis:

1. Kliendilt saadetakse taotlus oma juhile, kus on märgitud vajalik ühenduse kiirus, liikluse profiil ja IP-aadressimise parameetrid tunnelile (vaikimisi alamvõrk maskiga /30) ning marsruutimise tüüp (statika või BGP). Kliendi kontoris kohalikesse võrkudesse suunatud marsruutide edastamiseks kasutatakse IKEv2 protokolli etapi mehhanisme IPSecis vastava seadistusega kliendi ruuteris või need kuulutatakse BGP kaudu MPLSis kliendi taotluses näidatud eraldiseisva BGP AS-i kaudu. Seega kontrollib klient täielikult oma võrgumarsruutide teavet läbi kliendi ruuteri seadistuste.
2. Oma juhilt saab klient kontoandmed, mida on vaja oma VRF-i sisselülitamiseks:
   • VPN-HUB IP-aadress
   • Kasutajanimi
   • Tuvastusparool
3. Seadistab CPE, allpool on näidatud kaks näidet põhiseadistustest:Cisco jaoks variant:
   crypto ikev2 keyring BeelineIPsec_keyring
   peer Beeline_VPNHub
   address 62.141.99.183 –VPN-kontsentraator Beeline
   pre-shared-key
   !
   Statilise marsruutimise valiku puhul saab Vpn-hubi kaudu ligipääsetavate võrkude marsruudid määrata IKEv2 seadistuses, ja need kuvatakse automaatselt staatiliste marsruutidena CE marsruuditabelis. Neid seadeid on võimalik määrata ka klassikalisel viisil, nagu on allpool toodud.

   crypto ikev2 authorization policy FlexClient-author

   Marsruutide seadistamine CE marsruuteri kaudu on kohustuslik, kui kasutatakse staatilist marsruutimist CE ja PE vahel. Marsruutide andmete edastamine PE-le toimub automaatselt IKEv2 tunnelite avamisel.

   route set remote ipv4 10.1.1.0 255.255.255.0 – Kohalik kontori võ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 – Tunnel adresse
   tunnel source GigabitEthernet0/2 – Interneti juurdepääsu liides
   tunnel mode ipsec ipv4
   tunnel destination dynamic
   tunnel protection ipsec profile default
   !
   Klientide privaatsete võrkude marsruudid, mis on saadaval Beeline'i VPN-keskuse kaudu, saab määrata staatiliselt.

   ip route 172.16.0.0 255.255.0.0 Tunnel1
   ip route 192.168.0.0 255.255.255.0 Tunnel1

   Variant Huawei jaoks (ar160/120):
   ike local-name
   #
   acl name ipsec 3999
   rule 1 permit ip source 10.1.1.0 0.0.0.255 – Kohalik kontori võrk
   #
   aaa
   teenuse skeem IPSEC
   route set acl 3999
   #
   ipsec ettepanek ipsec
   esp autentimise algoritmo sha2-256
   esp krüpteerimise algoritmo aes-256
   #
   ike ettepanek default
   krüpteerimise algoritmo aes-256
   dh group2
   autentimise algoritmo sha2-256
   autentimise meetod eelnevalt jagatud
   integriteedi algoritmo hmac-sha2-256
   prf hmac-sha2-256
   #
   ike peer ipsec
   eelnevalt jagatud võti simple
   kohalik identifikaatori tüüp fqdn
   kaug-ide tüüp ip
   kaug-osa 62.141.99.183 –VPN-kontsentraator Beeline
   teenuse skeem IPSEC
   config-exchange request
   config-exchange set accept
   config-exchange set send
   #
   ipsec profiil ipsecprof
   ike-peer ipsec
   ettepanek ipsec
   #
   liides Tunnel0/0/0
   ip address 10.20.1.2 255.255.255.252 – Tunnel adresse
   tunnel-protokoll ipsec
   allikas GigabitEthernet0/0/1 – Interneti juurdepääsu liides
   ipsec profiil ipsecprof
   #
   Klientide privaatsete võrkude marsruudid, mis on saadaval Beeline'i VPN-keskuse kaudu, saab määrata staatiliselt.

   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

Saadud ühendusskeem näeb välja umbes selline:

Kui kliendil puuduvad mõningad põhilise konfiguratsiooni näited, siis aitame tavaliselt nende koostamisel ja teeme need kergesti kätte saadavaks teistele.

Dial-up CPE on the Internet is yet to be connected, a ping to the VPN tunnel's response part and any host within the VPN must be established, and that's it; we can consider the connection made.

In the next article, we will explain how we combined this scheme with IPSec and MultiSIM failover using Huawei CPE: we install our Huawei CPE for clients, which can utilize not only a wired internet connection but also 2 different SIM cards, with CPE automatically restructuring the IPSec tunnel either through wired WAN or via radio (LTE#1/LTE#2), achieving high reliability of the resultant service.

Special thanks to our RnD colleagues for preparing this article (and, of course, to the authors of these technical solutions)!

Allikas: habr.com