Kuidas pääseda Beline IPVPN-i läbi IPSec. Osa 1

Tere! A tõin välja, et satelliidid ja praht, mis asuvad alla 600 km, kukuvad orbitaalilt paariaastaga — atmosfääri takistuse tõttu, vähendades oluliselt Kessleri sündroomi võimalusi. SpaceX'i tegevus prahi osas tundub, nagu nad ei mõtleks üldse kosmosereostusele. Vaadates Starlinki elluviimise detaile, on mul raske ette kujutada paremat moodust prahi hulga vähendamiseks orbiidil. ma kirjeldasin meie MultiSIM teenuse tööd osas reservatsioon ja tasakaalustamine kanalid. Nagu mainitud, ühendame kliente võrguga läbi VPN-i ja täna räägin natuke rohkem VPN-ist ja meie võimalustest sellel alal.

Alustada tasub sellest, et meil kui sideteenuse osutajal on oma suur MPLS-võrk, mis on fikseeritud side klientide jaoks jagatud kaheks peamiseks segmendiks — see, mis on mõeldud otse Internetti juurdepääsuks, ja see, mida kasutatakse isoleeritud võrkude loomiseks — ja just läbi selle MPLS-segmendi liigub IPVPN (L3 OSI) ja VPLAN (L2 OSI) liiklus meie äriklientide jaoks.

Tavaliselt toimub kliendi ühendamine järgmiselt.

Kliendi büroosse paigaldatakse juurdepääsuliin lähimast võrgusoleku punktist (NODE MEN, PРL, BССС, FTTB jne) ning edasi, kanal määratakse transpordivõrgus vastava RE-MPLS marsruuterini, kus toome selle välja kliendi jaoks spetsiaalselt loodud VRF-i, arvesse võttes liiklusprofiili, mis kliendile vajalik (profiilimärgid valitakse iga juurdepääsu porte jaoks, tuginedes ip precedence väärtustele 0,1,3,5).

Kui mingil põhjusel ei suuda me kliendile viimase miili täielikult korraldada, näiteks kui kliendi büroo asub ärihoones, kus eelistatakse mõnda teist teenusepakkujat, või läheduses ei ole meie võrgusoleku punkti, siis pidid kliendid varem looma mitu IPVPN-võrku erinevates teenusepakkujates (mitte kõige kasumlikum arhitektuur) või iseseisvalt lahendama ligipääsu küsimused oma VRF-i juurde üle Interneti.

Paljud tegid seda IPVPN-interneti värava paigaldamisega — paigaldasid piirivõrgu marsruuteri (seadmestiku või mõne lahenduse Linuxi baasil), ühendasid üks port IPVPN-kanali ja teise — Interneti-kanali, käivitasid seal oma VPN-serveri ja ühendasid kasutajad läbi oma VPN-värava. Loomulikult tekitab selline skeem ka koormusi: sellist infrastruktuuri tuleb osata üles ehitada ja, mis kõige ebamugavam — kasutada ja arendada.

Kliendi elu lihtsustamiseks oleme loonud keskse VPN-hubi ja korraldanud toetuse interneti kaudu ühenduste tegemiseks, kasutades IPSec'i. See tähendab, et nüüd peavad kliendid lihtsalt seadistama oma ruuteri, et kasutada meie VPN-hubi IPSec-tunneli kaudu mistahes avalikus internetis, ning me suuname selle kliendi liikluse tema VRF-i.

Kellele see on kasulik

• Neile, kellel juba on suur IPVPN-võrk ja kes vajavad uusi ühendusi kiiresti.
• Kõigile, kes mingil põhjusel soovivad viia osa liiklust avalikust internetist IPVPN-i, kuid on varem kokku puutunud tehniliste piirangutega, mis on seotud mitmete teenusepakkujatega.
• Neile, kellel on praegu mitu eraldiseisvat VPN-võrku erinevatelt sideettevõtetelt. On kliente, kellel on edukalt korraldatud IPVPN nii Beeline'i, MegaFoni kui ka Rostelekoma jt poolt. Lihtsuse huvides võiks jääda ainult meie ühtsesse VPN, kõik teised kanalid teiste operaatorite kaudu suunatakse internetti, pärast mida ühendatakse IPVPN Beeline'iga IPSec'i ja nende operaatorite interneti kaudu.
• Neile, kellel on juba IPVPN-võrk, mis on asetatud interneti peale.

Kui kõik meie juurde üles seada, saavad kliendid täieliku toe VPN-i osas, tõsise infrastruktuuri reserveerimise ning tüüpilised seadistused, mis töötavad igas tuntud ruuteris (olgu see siis Cisco või Mikrotik, peaasi, et see toetaks normaalselt IPSec/IKEv2 ja standardiseeritud autentimismeetodeid). Muide, IPSec'i toetame praegu ainult seda, kuid plaanis on käivitada ka OpenVPN ja Wireguard, et kliendid saaksid protokollist sõltumatud ja veelgi lihtsamalt kõik meie juurde viia, samuti soovime hakata ühendama kliente arvutite ja mobiilsete seadmetega (süsteemi sisseehitatud lahendused, Cisco AnyConnect ja strongSwan ning sarnased). Sellise lähenemisega võib de facto infrastruktuuri julgelt operaatorile usaldada, jättes alles ainult CPE või hosti seadistamise.

Kuidas toimub ühendamise protsess IPSec-režiimis:

1. Klient esitab oma juhile taotluse, milles näitab vajalikku ühenduse kiirus, liiklusprofiil ja IP-aadressi parameetrid tunnelile (vaikimisi alajaotus maskiga /30) ja marsruutimise tüüp (staatiline või BGP). Klientide kohalike võrkude marsruutide edastamiseks ühendatud büroodes kasutatakse IPSec protokolli IKEv2 faasi mehhanisme koos vastavate seadistustega kliendi ruuteris või kuulutatakse need BGP kaudu MPLS-is, lähtudes kliendi esitatud privaatsetest BGP AS-idest. Seega kontrollib klient oma võrkude marsruutide teavet täielikult oma kluster-ruuteri seadete kaudu.
2. Oma juhilt saab klient arveldamisandmed, mida saab lisada oma VRF-i, näiteks:
   • VPN-HUBi IP-aadress
   • Kasutajanimi
   • Autentimise parool
3. Seadistab SRV, allpool on näha kaks baas конфигураatsiooni varianti:Cisco variant:
   crypto ikev2 keyring BeelineIPsec_keyring
   peer Beeline_VPNHub
   address 62.141.99.183 – Beeline VPN-keskus
   pre-shared-key
   !
   Staatilise marsruutimise variandi puhul võivad marsruudid, mis on saadaval VPN-hubi kaudu, olla määratud IKEv2 seadistuses ning need ilmuvad automaatselt staatiliste marsruutidena SRV marsruuditabelis. Need seadistused on võimalik teha ka standardsel viisil staatiliste marsruutide määramisel (vt allpool).

   crypto ikev2 authorization policy FlexClient-author

   Marsruut tagasi võrgustike küljest, mis on SRV ruuteri taga, on staatilise marsruutimise kohustuslik seadistus SRV ja PE vahel. Marsruutide andmete edastamine PE-le toimub automaatselt tunnelite tõusmise ajal IKEv2 interaktsiooni kaudu.

   route set remote ipv4 10.1.1.0 255.255.255.0 – Kohalik büroo 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 – Tunneliaadress
   tunnel source GigabitEthernet0/2 – Interneti-ühenduse liides
   tunnel mode ipsec ipv4
   tunnel destination dynamic
   tunnel protection ipsec profile default
   !
   Marsruute privaatsete klientide võrkudesse, mis on kergestatud Beeline 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

   Huawei (ar160/120) variant:
   ike local-name
   #
   acl name ipsec 3999
   reegl 1 lubab ip allika 10.1.1.0 0.0.0.255 – Kohalik büroo võrk
   #
   aaa
   teenuse-skeem IPSEC
   marsruut seadista acl 3999
   #
   ipsec ettepanek ipsec
   esp autentimise-algoritm sha2-256
   esp krüpteerimise-algoritm aes-256
   #
   ike ettepanek vaikimisi
   krüpteerimise-algoritm aes-256
   dh grupp2
   autentimise-algoritm sha2-256
   autentimise-viis eelhulga
   puhtuse-algoritm hmac-sha2-256
   prf hmac-sha2-256
   #
   ike partner ipsec
   eelhulga võti lihtne
   kohalik-id-tyyp fqdn
   kaug-id-tyyp ip
   kaug-aadress 62.141.99.183 – Beeline VPN-keskus
   teenuse-skeem IPSEC
   config-vahetus päring
   config-vahetus seadista aktsepteeri
   config-vahetus seadista saada
   #
   ipsec profiil ipsecprof
   ike-partner ipsec
   ettepanek ipsec
   #
   liides Tunnel0/0/0
   ip address 10.20.1.2 255.255.255.252 – Tunneliaadress
   tunnel-protokoll ipsec
   allikas GigabitEthernet0/0/1 – Interneti-ühenduse liides
   ipsec profiil ipsecprof
   #
   Klientide privaatsete võrkude marsruudid, mis on kergesti ligipääsetavad Beeline'i VPN keskuse kaudu, saab määrata staatiliselt

   ip marsruut-statiline 192.168.0.0 255.255.255.0 Tunnel0/0/0
   ip marsruut-statiline 172.16.0.0 255.255.0.0 Tunnel0/0/0

Saadud side skeem näeb välja umbes järgmiselt:

Kui klientidel puuduvad mõned põhikonfiguratsiooni näited - siis aitame tavaliselt nende väljatöötamisel ja teeme need kergesti kergesti ligipääsetavaks teistele.

Jäänud on ühendada CPE internetti, teha ping vastava VPN tunneli ja mingisuguse hosti sisse VPN-i ning kõik, saab juba öelda, et ühendus on loodud.

Järgmises artiklis räägime, kuidas me kombineerisime selle skeemi IPSec ja MultiSIM varundamisega CPE Huawei abil: seame klientidele meie CPE Huawei, milles saab kasutada mitte ainult juhtme interneti kanalit, vaid ka 2 erinevat SIM-kaarti, ning CPE kohandab automaatselt IPSec-tunneli kas juhtme WAN kaudu või raadio (LTE#1/LTE#2) kaudu, saavutades lõppteenuse kõrge usaldusväärsuse.

Eriline tänu selle artikli koostamise eest (ja tegelikult nende tehniliste lahenduste autoritele) meie RnD kolleegidele!

Allikas: habr.com