Saluton! EN Mi priskribis la laboron de nia MultiSIM-servo parte и kanaloj. Kiel menciite, ni konektas klientojn al la reto per VPN, kaj hodiaŭ mi rakontos al vi iom pli pri VPN kaj niaj kapabloj en ĉi tiu parto.
Indas komenci per tio, ke ni, kiel telekomunika operatoro, havas nian propran grandegan MPLS-reton, kiu por fiksliniaj klientoj estas dividita en du ĉefajn segmentojn - tiu, kiu estas uzata rekte por aliri Interreton, kaj tiu, kiu estas. uzata por krei izolitajn retojn - kaj estas tra ĉi tiu MPLS-segmento ke IPVPN (L3 OSI) kaj VPLAN (L2 OSI) trafiko fluas por niaj kompaniaj klientoj.
Tipe, klientkonekto okazas jene.
Alirlinio estas metita al la oficejo de la kliento de la plej proksima Punkto de Ĉeesto de la reto (nodo MEN, RRL, BSSS, FTTB, ktp.) kaj plue, la kanalo estas registrita tra la transportreto al la responda PE-MPLS. enkursigilo, sur kiu ni eligas ĝin al speciale kreita por la VRF-kliento, konsiderante la trafikan profilon, kiun la kliento bezonas (profilaj etikedoj estas elektitaj por ĉiu alirhaveno, surbaze de la ip-precedencaj valoroj 0,1,3,5, XNUMX).
Se ial ni ne povas plene organizi la lastan mejlon por la kliento, ekzemple, la oficejo de la kliento situas en komerca centro, kie alia provizanto estas prioritato, aŭ ni simple ne havas nian ĉeeston proksime, tiam antaŭe klientoj. devis krei plurajn IPVPN-retojn ĉe malsamaj provizantoj (ne la plej kostefika arkitekturo) aŭ sendepende solvi problemojn pri organizado de aliro al via VRF per Interreto.
Multaj faris tion instalante IPVPN-Interretan enirejon - ili instalis landliman enkursigilon (aparataro aŭ iun Linukso-bazitan solvon), konektis al ĝi IPVPN-kanalon per unu haveno kaj interretan kanalon kun la alia, lanĉis sian VPN-servilon sur ĝi kaj konektis. uzantoj per sia propra VPN-enirejo. Nature, tia skemo ankaŭ kreas ŝarĝojn: tia infrastrukturo devas esti konstruita kaj, plej maloportune, funkciigita kaj disvolvita.
Por faciligi la vivon al niaj klientoj, ni instalis centralizitan VPN-nabon kaj organizis subtenon por konektoj tra Interreto uzante IPSec, tio estas, nun klientoj nur bezonas agordi sian enkursigilon por labori kun nia VPN-nabo per IPSec-tunelo tra iu ajn publika Interreto. , kaj ni Ni liberigu la trafikon de ĉi tiu kliento al ĝia VRF.
Kiu trovos ĝin utila?
- Por tiuj, kiuj jam havas grandan IPVPN-reton kaj bezonas novajn konektojn en mallonga tempo.
- Ĉiu, kiu ial volas transdoni parton de la trafiko de la publika Interreto al IPVPN, sed antaŭe renkontis teknikajn limigojn asociitajn kun pluraj provizantoj de servoj.
- Por tiuj, kiuj nuntempe havas plurajn malsimilajn VPN-retojn tra malsamaj teleentreprenistoj. Estas klientoj, kiuj sukcese organizis IPVPN de Beeline, Megafon, Rostelecom, ktp. Por faciligi ĝin, vi povas resti nur ĉe nia ununura VPN, ŝanĝi ĉiujn aliajn kanalojn de aliaj funkciigistoj al la Interreto, kaj poste konekti al Beeline IPVPN per IPSec kaj la Interreto de ĉi tiuj telefonistoj.
- Por tiuj, kiuj jam havas IPVPN-reton supermetitan en la Interreto.
Se vi disvastigas ĉion kun ni, tiam klientoj ricevas plenan VPN-subtenon, seriozan infrastrukturan redundon kaj normajn agordojn, kiuj funkcios sur iu ajn enkursigilo al kiu ili kutimas (ĉu ĝi estas Cisco, eĉ Mikrotik, la ĉefa afero estas, ke ĝi povas ĝuste subteni. IPSec/IKEv2 kun normigitaj aŭtentikigmetodoj). Cetere, pri IPSec - nun ni nur subtenas ĝin, sed ni planas lanĉi plenan funkciadon de kaj OpenVPN kaj Wireguard, por ke klientoj ne povu dependi de la protokolo kaj eĉ pli facile estas preni kaj transdoni ĉion al ni, kaj ni ankaŭ volas komenci konekti klientojn de komputiloj kaj porteblaj aparatoj (solvoj enkonstruitaj en la OS, Cisco AnyConnect kaj strongSwan kaj similaj). Kun ĉi tiu aliro, la fakta konstruado de la infrastrukturo povas esti sekure transdonita al la funkciigisto, lasante nur la agordon de la CPE aŭ gastiganto.
Kiel funkcias la koneksa procezo por IPSec-reĝimo:
- La kliento lasas peton al sia administranto, en kiu li indikas la bezonatan konektan rapidon, trafikan profilon kaj IP-adresadparametrojn por la tunelo (defaŭlte, subreto kun /30-masko) kaj la specon de enrutado (senmova aŭ BGP). Por transdoni itinerojn al la lokaj retoj de la kliento en la ligita oficejo, la IKEv2-mekanismoj de la IPSec-protokola fazo estas uzataj uzante la taŭgajn agordojn sur la klientenkursigilo, aŭ ili estas reklamitaj per BGP en MPLS de la privata BGP AS specifita en la aplikaĵo de la kliento. . Tiel, informoj pri la itineroj de klientretoj estas tute kontrolitaj de la kliento per la agordoj de la klienta enkursigilo.
- En respondo de sia administranto, la kliento ricevas kontadajn datumojn por inkluzivi en sia VRF de la formo:
- VPN-HUB IP-adreso
- Ensalutu
- Aŭtentikiga pasvorto
- Agordas CPE, sube, ekzemple, du bazaj agordaj opcioj:
Opcio por Cisco:
crypto ikev2 ŝlosilringo BeelineIPsec_keyring
samulo Beeline_VPNHub
adreso 62.141.99.183 –VPN-nabo Beeline
pre-shared-key <Aŭtentikiga pasvorto>
!
Por la senmova vojiga opcio, itineroj al retoj alireblaj per la Vpn-hub povas esti specifitaj en la IKEv2-agordo kaj ili aŭtomate aperos kiel senmovaj itineroj en la CE-vojigtabelo. Ĉi tiuj agordoj ankaŭ povas esti faritaj per la norma metodo de agordo de senmovaj itineroj (vidu malsupre).crypto ikev2 rajtigopolitiko FlexClient-author
Itinero al retoj malantaŭ la CE-enkursigilo - deviga agordo por senmova vojigo inter CE kaj PE. La translokigo de itinerdatenoj al la PE estas aranĝita aŭtomate kiam la tunelo estas levita tra IKEv2-interagado.
vojaro fora ipv4 10.1.1.0 255.255.255.0 -Oficeja loka reto
!
crypto ikev2 profilo BeelineIPSec_profile
identeco loka <saluto>
aŭtentikigo loka antaŭdivido
aŭtentikigo fora antaŭdivido
Ŝlosilringo loka BeelineIPsec_keyring
aaa rajtiga grupo psk listo grupo-aŭtoro-listo FlexClient-aŭtoro
!
crypto ikev2 kliento flexvpn BeelineIPsec_flex
samulo 1 Beeline_VPNHub
kliento konekti Tunnel1
!
crypto ipsec transform-set TRANSFORM1 esp-aes 256 esp-sha256-hmac
reĝima tunelo
!
crypto ipsec profilo defaŭlta
aro transform-aro TRANSFORM1
starigis ikev2-profile BeelineIPSec_profile
!
interfaco Tunnel1
IP-adreso 10.20.1.2 255.255.255.252 –Tunela adreso
tunela fonto GigabitEthernet0/2 -Interreta aliro interfaco
tunela reĝimo ipsec ipv4
tunelo celloko dinamika
tunela protekto ipsec profilo defaŭlta
!
Itineroj al la privataj retoj de la kliento alireblaj per la Beeline VPN-koncentrilo povas esti fiksitaj statike.ip vojo 172.16.0.0 255.255.0.0 Tunnel1
ip vojo 192.168.0.0 255.255.255.0 Tunnel1Opcio por Huawei (ar160/120):
ike loka-nomo <saluto>
#
akl nomo ipsec 3999
regulo 1 permesi ip fonto 10.1.1.0 0.0.0.255 -Oficeja loka reto
#
aaa
servo-skemo IPSEC
itinero aro acl 3999
#
ipsec propono ipsec
esp aŭtentikiga-algoritmo sha2-256
esp ĉifrado-algoritmo aes-256
#
ike propono defaŭlta
ĉifrado-algoritmo aes-256
dh grupo2
aŭtentikigo-algoritmo sha2-256
aŭtentikig-metodo antaŭdividado
integreco-algoritmo hmac-sha2-256
prf hmac-sha2-256
#
ike peer ipsec
pre-shared-key simpla <Aŭtentikiga pasvorto>
loka-id-tipo fqdn
remote-id-tipo ip
malproksima adreso 62.141.99.183 –VPN-nabo Beeline
servo-skemo IPSEC
agorda interŝanĝo-peto
konfig-interŝanĝo aro akcepti
konfig-interŝanĝo aro sendi
#
ipsec profilo ipsecprof
ike-peer ipsec
propono ipsec
#
interfaco Tunelo0/0/0
IP-adreso 10.20.1.2 255.255.255.252 –Tunela adreso
tunelo-protokolo ipsec
fonto GigabitEthernet0/0/1 -Interreta aliro interfaco
ipsec profilo ipsecprof
#
Itineroj al la privataj retoj de la kliento alireblaj per la Beeline VPN-koncentrilo povas esti fiksitaj statikeip 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
La rezulta komunika diagramo aspektas kiel ĉi tio:
Se la kliento ne havas kelkajn ekzemplojn de la baza agordo, tiam ni kutime helpas kun ilia formado kaj disponigas ilin al ĉiuj aliaj.
Restas nur konekti la CPE al la Interreto, ping al la respondparto de la VPN-tunelo kaj ajna gastiganto ene de la VPN, kaj jen ĝi, ni povas supozi, ke la konekto estis farita.
En la sekva artikolo ni rakontos al vi kiel ni kombinis ĉi tiun skemon kun IPSec kaj MultiSIM Redundancy uzante Huawei CPE: ni instalas nian Huawei CPE por klientoj, kiuj povas uzi ne nur kablan Interretan kanalon, sed ankaŭ 2 malsamajn SIM-kartojn, kaj la CPE. aŭtomate rekonstruas IPSec-tunelo aŭ per kablita WAN aŭ per radio (LTE#1/LTE#2), realigante altan misfunkciadon de la rezulta servo.
Specialan dankon al niaj RnD-kolegoj pro preparado de ĉi tiu artikolo (kaj, fakte, al la aŭtoroj de ĉi tiuj teknikaj solvoj)!
fonto: www.habr.com