Cześć! W poprzednim poście Opisałem działanie naszej usługi MultiSIM w zakresie rezerwacji i balansowania kanałów. Jak wcześniej wspomniano, klientów łączymy z siecią przez VPN, a dzisiaj opowiem nieco więcej o VPN i naszych możliwościach w tym zakresie.
Warto zacząć od tego, że jako operator telekomunikacyjny posiadamy własną ogromną sieć MPLS, która dla klientów z komunikacją stacjonarną jest podzielona na dwa główne segmenty — jeden używany bezpośrednio do dostępu do internetu, a drugi do tworzenia izolowanych sieci — i to przez ten segment MPLS przechodzi ruch IPVPN (L3 OSI) i VPLAN (L2 OSI) dla naszych klientów korporacyjnych.
Zwykle podłączenie klienta odbywa się w następujący sposób.
Do biura klienta kładziona jest linia dostępu z najbliższego punktu obecności sieci (węzeł MEN, PRL, BSSC, FTTB itd.), a następnie kanał jest przekazywany przez sieć transportową do odpowiedniego routera RE-MPLS, na którym wyprowadzamy go do specjalnie tworzonego dla klienta VRF z uwzględnieniem profilu ruchu, który jest wymagany przez klienta (znaczniki profilu wybierane są dla każdego portu dostępowego, opierając się na wartościach ip precedence 0, 1, 3, 5).
Jeśli z jakiegoś powodu nie możemy w pełni zorganizować ostatniej mili dla klienta, na przykład, gdy biuro klienta znajduje się w centrum biznesowym, gdzie priorytet ma inny dostawca, lub obok po prostu nie ma naszego punktu obecności, to wcześniej klienci musieli tworzyć kilka sieci IPVPN u różnych dostawców (nieoptymalna pod względem kosztów architektura) lub samodzielnie rozwiązywać kwestie organizacji dostępu do swojego VRF przez sieć internetową.
Wielu robiło to za pomocą zainstalowania bramy IPVPN — instalowano router brzegowy (sprzętowy lub rozwiązanie oparte na Linuxie), łączono z nim jednym portem IPVPN-kanał, a drugim — kanał internetowy, uruchamiając na nim własny serwer VPN i łączyli użytkowników przez swoją własną bramę VPN. Oczywiście, taki schemat generuje również obciążenia: taką infrastrukturę trzeba umieć budować i, co najważniejsze — eksploatować i rozwijać.
Aby uprościć życie naszym klientom, zainstalowaliśmy centralny hub VPN i zorganizowaliśmy wsparcie dla połączeń przez Internet z użyciem IPSec, co oznacza, że klienci muszą tylko skonfigurować swoje routery do pracy z naszym hubem VPN przez tunel IPSec przez dowolny publiczny Internet, a my puścimy ruch tego klienta w jego VRF.
Dla kogo to będzie przydatne
- Dla tych, którzy już mają dużą sieć IPVPN i potrzebują nowych połączeń w krótkim czasie.
- Dla wszystkich, którzy z jakiegoś powodu chcą przenieść część ruchu z publicznego Internetu do IPVPN, ale wcześniej napotykali ograniczenia techniczne związane z wieloma dostawcami usług.
- Dla tych, którzy obecnie mają kilka rozproszonych sieci VPN u różnych operatorów telekomunikacyjnych. Są klienci, którzy skutecznie zorganizowali IPVPN zarówno od Beeline, jak i od MegaFon, a także od Rostelekom itp. Aby uprościć, można pozostać tylko na naszej jednolitej VPN, a wszystkie inne kanały innych operatorów przełączyć na Internet, a następnie połączyć się z IPVPN Beeline przez IPSec i Internet od tych operatorów.
- Dla tych, którzy już mają sieć IPVPN nałożoną na Internet.
Jeśli wszystko rozwinie się u nas, klienci otrzymują kompleksowe wsparcie dotyczące VPN, poważne rezerwowanie infrastruktury oraz typowe ustawienia, które będą działać na każdym znanym routerze (niezależnie czy to Cisco czy Mikrotik, ważne, aby poprawnie obsługiwał IPSec/IKEv2 z ustandaryzowanymi metodami autoryzacji). A propos IPSec — obecnie wspieramy tylko ten protokół, ale w planach mamy uruchomienie pełnej współpracy i z OpenVPN, i z Wireguard, aby klienci nie musieli zależeć od protokołu i jeszcze łatwiej mogli przenieść wszystko do nas, a także planujemy zacząć łączyć klientów z komputerów i urządzeń mobilnych (wbudowane rozwiązania w systemie operacyjnym, Cisco AnyConnect, strongSwan i podobne). Przy takim podejściu de facto budowę infrastruktury można z powodzeniem powierzyć operatorowi, pozostawiając jedynie konfigurację CPE lub hosta.
Jak przebiega proces łączenia w trybie IPSec:
- Klient składa wniosek do swojego menedżera, w którym określa wymaganą prędkość połączenia, profil ruchu oraz parametry adresacji IP dla tunelu (domyślnie podsieć z maską /30) i typ routingu (statyczny lub BGP). Do przesyłania tras do lokalnych sieci klienta w podłączonym biurze wykorzystywane są mechanizmy IKEv2 fazy protokołu IPSec dzięki odpowiednim ustawieniom na routerze klienta, lub ogłaszane przez BGP w MPLS z określonego wniosek przez klienta prywatnego AS BGP. W ten sposób informacje o trasach sieci klientów są w pełni kontrolowane przez klienta za pośrednictwem ustawień routera klienta.
- W odpowiedzi od swojego menedżera klient otrzymuje dane do rozliczeń do dodania do swojego VRF w następującej formie:
- Adres IP VPN-HUB
- Login
- Hasło autoryzacji
- Konfiguruje CPE, poniżej, dla przykładu dwa warianty podstawowej konfiguracji:Wariant dla Cisco:
crypto ikev2 keyring BeelineIPsec_keyring
peer Beeline_VPNHub
address 62.141.99.183 –VPN koncentrator Biełain
pre-shared-key
!
W przypadku wariantu ze statycznym routowaniem trasy do sieci dostępnych przez Vpn-hub mogą być określone w ustawieniach IKEv2 i automatycznie pojawią się jako statyczne trasy w tablicy routingu CPE. Te ustawienia można również przeprowadzić standardowym sposobem definiowania tras statycznych (patrz poniżej).crypto ikev2 authorization policy FlexClient-author
Trasa do sieci za routerem CPE – obowiązkowe ustawienie w przypadku statycznego routowania między CPE a PE. Przesyłanie danych tras do PE odbywa się automatycznie przy włączonym tunelu poprzez interakcję IKEv2.
route set remote ipv4 10.1.1.0 255.255.255.0 –Lokalna sieć biura
!
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
tryb tunelu
!
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 –Adres tunelu
tunnel source GigabitEthernet0/2 –Interfejs dostępu do Internetu
tunnel mode ipsec ipv4
tunnel destination dynamic
tunnel protection ipsec profile default
!
Trasy do prywatnych sieci klienta, dostępnych przez VPN koncentrator Biełain, można określić statycznie.ip route 172.16.0.0 255.255.0.0 Tunnel1
ip route 192.168.0.0 255.255.255.0 Tunnel1Wariant dla Huawei (ar160/120):
ike local-name
#
acl name ipsec 3999
reguła 1 zezwala na IP źródłowe 10.1.1.0 0.0.0.255 –Lokalna sieć biura
#
aaa
schemat usługi IPSEC
ustaw trasę acl 3999
#
propozycja ipsec ipsec
algorytm uwierzytelniania esp sha2-256
algorytm szyfrowania esp aes-256
#
propozycja ike domyślna
algorytm szyfrowania aes-256
grupa dh2
algorytm uwierzytelniania sha2-256
metoda uwierzytelniania pre-share
algorytm integralności hmac-sha2-256
prf hmac-sha2-256
#
peer ike ipsec
klucz pre-shared prosty
typ lokalnego identyfikatora fqdn
typ identyfikatora zdalnego ip
adres zdalny 62.141.99.183 –VPN koncentrator Biełain
schemat usługi IPSEC
wymiana-configu żądanie
wymiana-configu ustaw akceptuj
wymiana-configu ustaw wyślij
#
profil ipsec ipsecprof
peer ike ipsec
propozycja ipsec
#
interfejs Tunnel0/0/0
ip address 10.20.1.2 255.255.255.252 –Adres tunelu
protokół tunelu ipsec
źródło GigabitEthernet0/0/1 –Interfejs dostępu do Internetu
profil ipsec ipsecprof
#
Trasy do prywatnych sieci klienta dostępnych przez VPN koncentrator Bilań można ustawić statycznieip trasa-statystyczna 192.168.0.0 255.255.255.0 Tunnel0/0/0
ip trasa-statystyczna 172.16.0.0 255.255.0.0 Tunnel0/0/0
Otrzymany schemat połączenia wygląda mniej więcej tak:
Jeśli klient nie ma żadnych przykładów podstawowej konfiguracji, zwykle pomagamy w ich tworzeniu i udostępniamy je wszystkim innym.
Pozostaje połączyć CPE z Internetem, wykonać ping do odpowiedniej części tunelu VPN i jakiegoś hosta wewnątrz VPN, i wszystko - można uznać, że połączenie zostało nawiązane.
W następnym artykule opowiemy, jak połączyliśmy ten schemat z IPSec i MultiSIM rezerwacją za pomocą CPE Huawei: instalujemy naszym klientom nasze CPE Huawei, które może korzystać nie tylko z przewodowego kanału internetowego, ale także z 2 różnych kart SIM, a CPE automatycznie przebudowuje tunel IPSec albo przez przewodowy WAN, albo przez radio (LTE#1/LTE#2), realizując wysoki poziom niezawodności finalnej usługi.
Szczególne podziękowania za przygotowanie tego artykułu (i, właściwie, autorom tych rozwiązań technicznych) kolegom z naszego RnD!
Źródło: habr.com
