SKALOWALNE SZYFROWANIE USŁUG W SIECI OPERATORA - przykład wdrożenia Robert Ślaski Chief Network Architect CCIE#10877 PLNOG9 22-23 października 2012 Kraków ATM Systemy Informatyczne S.A.
Zapraszamy na pokład! Nasz pacjent Nasze narzędzie Pacjent kontra narzędzie Przebieg operacji http://www.pbase.com/flying_dutchman/ 2
NASZ PACJENT 3
Nasz pacjent - usługa Zintegrowanej Komunikacji Wdrażana w ramach budowy sieci operatorskiej usługa ogólnopolskiego Systemu Zintegrowanej Komunikacji (SZK) Świadczona ma być przez Operatora dla wszystkich Użytkowników sieci Zapewni łączność VoIP pomiędzy starymi systemami PBX użytkowników Zapewni obsługę telefonii IP (centralne IP PABX) Da ogromne możliwości funkcjonalne, nową jakość pracy Usługi dodatkowe Mobilność użytkowników Dostępność pod jednym numerem telefonu Wideo Audio i Wideo konferencje Jednorodne styki z sieciami operatorów 4
System Zintegrowanej Komunikacji - struktura Planowana struktura Systemu Zintegrowanej Komunikacji 17 klastrów Cisco Unified Communications Manager 34 gatekeepery 2 directory gatekeepery Na początek ponad 1000 bram głosowych ze stykami do PBX użytkowników Tysiące telefonów IP Centralny styk do PSTN 5 użytkowników z ponad 100 000 abonentów w pierwszym etapie 5
Wymagania techniczne pacjenta Wymagane jest szyfrowanie całego ruchu w systemie (ruchu kontrolnego jak i danych) Zapewnienie przewagi technologicznej Metoda zabezpieczenia transmisji przy niektórych nie do końca bezpiecznej natury łączach dostępowych Z szyfrowaniem mają działać połączenia głosowe VoIP, telefonia IP, wideo oraz faksy (w tym również wcześniej zaszyfrowane) Ze względu na sposób dołączenia i topologię dołączenia najmniejszych lokalizacji, pożądane jest, aby ruch (nawet po zaszyfrowaniu) podążał ścieżkami routingu sieci podkładowej Architektura szyfrowania dla potrzeb SZK powinna również móc być wykorzystana w celu szyfrowania innych usług transmisji danych 6
Wymagania techniczne pacjenta Niezawodność każde województwo musi działać autonomicznie w przypadku awarii System ma być skalowalny musi obsłużyć kilkadziesiąt tysięcy lokalizacji Trzeba obsłużyć wiele różnych typów routerów wykorzystywanych w systemie SZK operatora oraz w jako bramy głosowe użytkowników - (Cisco 38xx, 29xx, 39xx, 7200, ASR) Możliwość dołączenia bram głosowych non-cisco 7
Zaprojektowana architektura szyfrowania Systemu Zintegrowanej Komunikacji Decyzja: szyfrowanie realizowane będzie przez gatekeepery i bramy głosowe 8
NASZE NARZĘDZIE 9
Nasze narzędzie: GETVPN GETVPN (Group Encrypted Transport VPN) Szyfrowanie beztunelowe W przeciwieństwie do klasycznego IPSec, GETVPN nie zestawia tuneli - możliwa jest wymiana ruchu między więcej niż dwoma routerami (w obrębie całej grupy routerów) Ergo: bezproblemowe szyfrowanie multicastów Zewnętrzny nagłówek IPSec ma te same adresy, co oryginalne adresy IP - routing pakietów odbywa się tymi samymi drogami, co ruchu cleartext Wspiera PKI Kluczowy element decyzyjny przy wyborze tej technologii Technologia Cisco, ale oparta na RFC 3547 (The Group Domain of Interpretation) są podobne rozwiązania, np. Group VPN Junipera Ponadto: obsługa wielu niezależnych grup, wsparcie dla VRF 10
GETVPN - przypomnienie lub zapoznanie Technologia scentralizowana Key Server (KS) Control plane (centralna inteligencja) Ustala polityki, generuje klucze, rejestruje GM Group Member (GM) Data plane, (rozproszona siła szyfrowania) Klient rejestrujący się do KS Jak to działa - w skrócie 1. Rejestracja GM w KS 2. KS wysła GM klucze i polityki 3. KS cykliczne ponownie wysyła klucze (proces rekey) 11
GETVPN - przypomnienie lub zapoznanie Key Encryption Key (KEK) Key Server Centralna polityka grupy Traffic Encryption Key (TEK) Group Member Zwykłe routery Group Member Group Member Group Member 12
Jak wygląda pakiet w GETVPN? Zewnętrzny nagłówek zachowuje oryginalne adresy IP i DSCP ESP z nieistotnym Sequence Number Narzut prawie* ten sam co przy standardowym IPSec Tunnel Mode *Opcjonalnie Time-Based Anti-Replay (TBAR) Funkcjonalność zastępująca brakujący ESP Sequence Number Dodatkowe 12 bajtów Protocol 99 (IANA Any private encryption scheme ) Group Member Router Router Group Member 10.1.1.4 10.1.2.32 crypto-mapa 13
Pakiety w GETVPN z TBAR i bez Enkapsulacja bez TBAR 10.1.1.4 10.1.2.32 Nagłówek ESP (SPI) 10.1.1.4 10.1.2.32 Dane IP 10.1.1.4 10.1.2.32 Dane IP Stopka ESP 10.1.1.4 10.1.2.32 Dane IP Enkapsulacja z TBAR 7 3 9 4 5 Znacznik czasowy 10.1.1.4 10.1.2.32 Nagłówek ESP (SPI) Cisco Meta Data Znacznik czasowy 7 4 0 2 3 10.1.1.4 10.1.2.32 Dane IP 10.1.1.4 10.1.2.32 Dane IP Stopka ESP 10.1.1.4 10.1.2.32 Dane IP 14
TBAR zasada działania 10.1.1.4 10.1.2.32 Nagłówek ESP (SPI) Cisco Meta Data 10.1.1.4 10.1.2.32 Dane IP Stopka ESP ESP/SPI TEK Deszyfracja Wyślij 10.1.1.4 10.1.2.32 Dane IP Znacznik czasowy Tak! pasuje? Kosz Nie! 7 4 0 2 3 ID porównaj OK! Kosz zbyt wcześnie lub zbyt późno 15
Wiele KS wydajność i niezawodność Primary KS (jeden) Wybierany spośród KS w grupie Generuje i dystrybuuje klucze Secondary KS (wiele) Monitoruje Primary Powiadamia go o nowych GM Funkcje wspólne: rejestrowanie GM Group Member Primary KS COOP (Cooperative Protocol) Zwykłe routery Secondary KS Group Member Group Member 16
Wiele KS wydajność i niezawodność Key Primary Server Secondary Key Server GET VPN Group Member Group Member Secondary Key Server COOP Rejestracja Klucze i polityki 17
Proces rekey - multicastowy Łatwiejszy albo trudniejszy niż unicastowy Retry = 1, Interval = 60 sec t -3600 t -420 10 % 5 % t -360 t -180 t -30 t 0 18
Proces rekey - unicastowy Łatwiejszy albo trudniejszy niż multicastowy Retry = 1, Interval = 60 sec t -3600 t -420 10 % 5 % t -360 t -180 t -30 t 0 19
Konfiguracja GM dość banalna Przypięcie crypto-mapy do interfejsu interface Serial0/0 ip address 192.168.1.14 255.255.255.252 crypto map CMAP Powiązanie crypto-mapy z GETVPN crypto map CMAP 10 gdoi set group GET_WAN match address ACL_EXCEPTIONS Konfiguracja lokalnych wyjątków ip access-list extended ACL_EXCEPTIONS deny ip host 192.168.1.14 host 192.168.1.13 deny tcp host 192.168.1.14 eq ssh any Konfiguracja powiązania z grupą GETVPN crypto gdoi group GET_WAN identity number 3333 server address ipv4 <ks1_address> server address ipv4 <ks2_address> ATM Systemy Informatyczne S.A. 20
Konfiguracja KS też niezbyt trudna Definicja grupy GETVPN crypto gdoi group GET_WAN identity number 3333 <- GROUP ID server local <- KEY SERVER rekey retransmit 40 number 3 <- REKEY RETRANSMITS rekey authentication mypubkey rsa my_rsa <- KS MSG AUTHENTICATION authorization address ACL_MEMBERS <- GROUP MEMBER AUTHORIZATION sa ipsec 1 <- SECURITY ASSOCIATION profile gdoi-p <- CRYPTO ATTRIBUTES SELECTION match address ipv4 CRYPTO_ACL <- ENCRYPTION POLICY LAN-to-LAN no replay <- NO ANTI-REPLAY address ipv4 <ks_address> <- KS ADDRESS Definicja członków grupy którzy mają prawo się dołączać ip access-list extended ACL_MEMBERS <- GM AUTH LIST permit <ks_peer_address> <- PEER KS permit <gm_address> <- GROUP MEMBER Definicja polityki szyfrowania w grupie ip access-list extended CRYPTO_ACL <- ENCRYPTION POLICY deny udp any eq 848 any eq 848 <- ALLOW GDOI permit ip 10.0.0.0 0.255.255.255 10.0.0.0 0.255.255.255 <- UNICAST permit ip 10.0.0.0 0.255.255.255 232.0.0.0 0.255.255.255 <- MULTICAST 21
Sprzęt dla GETVPN Key Server - routery Cisco serii 28xx, 38xx, 29xx, 39xx, 7200, (od jakiegoś czasu również ASR1000) Group Member - routery Cisco serii 87x 28xx, 38xx, 29xx, 39xx, 7200 ASR1000 22
PACJENT KONTRA NARZĘDZIE 23
Pacjent kontra narzędzie - Problem 1: wydajność GMów (ISR) 3945 3845 / AIM 3825 / AIM 2951 1941 2851 / AIM JEST OK 1841 / AIM 871 IMIX, 70% CPU 150 M 300M 450 M 600 M 750 M 900 M 24
Pacjent kontra narzędzie - Problem 1: wydajność GMów (nie-isr) ASR1000 ESP20 ASR1000 ESP10 ASR1000 ESP5 7200 G2/VSA 7200 G2/ VAM2+ 7200 G1/ VAM2+ JEST OK IMIX, 70% CPU 0.500 G 2.0 G 1.0 G 1.5 G 2.5 G 3.0 G 25
Pacjent kontra narzędzie - Problem 2: uwarunkowania KS Problem bardziej złożony, zależy od: Liczby GMów per jeden KS Czasu życia klucza TEK (domyślnie 3600s) Wymaganej liczby rejestracji na sekundę (zależna od platformy oraz PSK/PKI) Wymaganej liczby rekey na sekundę (dla unicast rekey) PSK: 150 s/okno * 30 rej/s = 4500 rej/okno Dla 3000 GM wymagany jest minimum 1 KS Typowo liczone okno rejestracji: OKNO_REJ = TEK_LIFETIME * 5% - 30s Przykład: 3000 GMów, domyślny czas klucza TEK, okno rejestracji 150 sek, platforma wspiera 30 rejestracji/s dla PSK i 12 rejestracji/s dla PKI PKI: 150 s/okno * 12 rej/s = 1800 rej/okno Dla 3000 GM wymagane są minimum 2 KS 26
Problem 2 - wydajność KS dla różnych systemów 7200, PSK 7200, PKI 3845, PSK 3825, PSK 2900, PKI 2851, PSK 2821, PSK 1841, PSK Maks. rekomendowana liczba GM w grupie Maksymalna wydajność: 7200+VSA PSK = 100 rejestracji /s 7200+VSA PKI = 12 rejestracji /s 3900 PSK > 80 rejestracji /s 7206 PSK > 33 rejestracji /s 3800 PSK = 16 rejestracji /s 2900 PSK > 6 rejestracji /s 2800 PSK = 6 rejestracji /s Wybieramy 7201 ale nie jest dobrze 100 200 400 600 800 1000 2000 5000 27
Problem 2 - analiza per przykładowa grupa, dla C7200 7200+VSA: PSK - 100 rejestracji /s, PKI = 12 rejestracji /s Obciążenie KS = #GM / Okno_rej / #KS PSK 1 KS 2 KS Obciążenie KS: 33 rejestr/s LF: 33 / 100 = 33% Obciążenie KS: 16 rejestr/s LF: 16 / 100 = 16% LF: Load Factor 1 KS Obciążenie KS: 33 rejestr/s LF: 33 / 12 = 270% TEK 3600 2 KS Obciążenie KS: 16 rejestr/s LF: 16 / 12 = 139% TEK 3600 PKI 2 KS Obciążenie KS: 7.3 rejestr/s LF: 7.3 / 12 = 60% TEK 7200 4 KS Obciążenie KS: 4 rejestr/s LF: 4 / 12 = 33% 8 KS Obciążenie KS: 2 rejestr/s LF: 2 / 12 = 17% 250 500 1000 2000 3000 4000 5000 28
Problem 2: - wielkość grupy GETVPN Zademonstrowana w testach wielkość grupy VPN to 5000 GMów - daleko poniżej wymaganej skalowalności sieci Współczynnik obciążenia KS (Load Factor) rośnie wraz ze wzrostem grupy Możemy go obniżyć przez wydłużenie timerów TEK i okna rejestacji Oraz zwiększenie liczby KSów per grupa GET Ale w jednej grupie może być tylko do 8 współpracujących KSów (a w niektórych wersjach oprogramowania nawet 7) Rozproszenie geograficzne jednej dużej grupy może skutkować problemami przy awariach (scenariusz split / merge grupy GET) Ups może zaparkujmy temat 29
Pacjent kontra narzędzie - Problem 3: sposób realizacji rekey Multicast Unicast Potencjalnie większa skalowalność rozwiązania Wymaga budowy sieci multicastowej Jeśli nie ma VRF-Aware GDOI, multicasty muszą krążyć w sieci użytkownika Potencjalnie mniejsza skalowalność rozwiązania Bezproblemowy od strony routingu Wstępnie wybieramy unicast 30
Pacjent kontra narzędzie - Problem 4: To PKI or not to PKI? W zasadzie nie było wyboru Skala systemu Silna presja przyszłego operatora na użycie PKI Konieczność dołączania do VPN urządzeń zewnętrznych użytkowników (kwestie operacyjne) Wsparcie w GETVPN autoryzacji również dla PKI Niespodzianka: brak wsparcia PSK w GETVPN w ASR1000 (wówczas) Decyzja: na 100% będzie PKI 31
Pacjent kontra narzędzie - Problem 5: jak obsłużyć wiele VPNów? Metoda 1 osobne KS dla osobnych VPNów Wspierana nakładająca się adresacja Niezbyt efektywna kosztowo (KSy się mnożą razem z VPNami) Prosta konfiguracja sieci, większe bezpieczeństwo Grupy KS GM Polityka Orendż PE PE KS Orendż VRF: Orendż VRF: Orendż GM KS Grin Grupy KS Polityka Grin VRF: Grin VRF: Grin GM GM 32
Pacjent kontra narzędzie - Problem 5: jak obsłużyć wiele VPNów? Metoda 2 KS współdzielone między VPNami Adresacja musi być globalnie spójna Efektywne wykorzystanie KSów Wybieramy 2 Konieczność zapewnienia bezpiecznej wymiany ruchu między VPNami Grupy KS GM Polityka Orendż Polityka Grin PE PE VRF: Orendż GM KS VRF: Control GM VRF: Grin GM 33
Pacjent kontra narzędzie - Problem 6: VPN - a co z VRFami? Prawdopodobnie będzie potrzeba zagetować kilka VRF per pudełko Można w jednym pudełku używać GETVPN z VRF, przy kilku założeniach Terminologia FVRF (Front-door VRF) strona niebezpieczna Inside VRF (IVRF) strona zabezpieczana GETVPN i VRF-Lite Wejście i wyjście muszą być w tym samym VRF Osobne crypto-mapy na interfejsach Ruch nie może przeciekać między VRFami Jest OK crypto mapa IVRF-1 IVRF-2 crypto mapa 34
Pacjent kontra narzędzie - Problem 7: VRFy a rejestracja do grup Dwie wspierane opcje Klasyczne GDOI Osobne tożsamości per VRF Rejestracja z tego samego VRFu co grupa VRF-Aware GDOI Wspólna tożsamość dla VRFów Rejestracja z osobnego VRFu, wspólnego dla wszystkich grup Ta sama tożsamość IKE autoryzacja nie grupy, ale urządzenia ASR1000 nie wspiera(ł) tej opcji Opcja klasyczna IVRF-1 IVRF-2 IVRF-1 IVRF-2 FVRF FVRF tożsamość współdzielona crypto mapa Orendż tożsamość Orendź tożsamość Grin crypto mapa Grin crypto mapa Orendż crypto mapa Grin 35
Pacjent kontra narzędzie - Problem 8: jak to zebrać do kupy? Podsumowując: wymagania naszego pacjenta, warunki brzegowe i niuanse technologiczne są częściowo nieco wzajemnie sprzeczne ze sobą Wymagana skalowalność całości jest daleko mniejsza niż udowodnione możliwości pojedynczej grupy (5000 GMów) Konieczność użycia PKI znacząco obniża wydajność KSów Ograniczony budżet wymaga ograniczenia liczby KSów, co wraz z niższą ich wydajnością mocno obniża teoretyczną skalowalność grupy. Brak VRF-Aware GET powoduje konieczność zapewnienia wymiany ruchu między VPNami KSów i wieloma VPNami GMów Liczba punktów wymiany ruchu między VPNami jest skończona i mniejsza niż liczba województw (co łamie warunek autonomii pojedynczego województwa) Pfffff.. 36
PRZEBIEG OPERACJI 37
Architektura naszego systemu szyfrowania Mimo tych wszystkich trudności - będzie szyfrowanie GETVPN! Udało się zaprojektować architekturę, która godzi sprzeczne wymagania Podział na domeny wojewódzkie Osobne grupy GET per województwo Dla obejścia ograniczeń skalowalności GET, wykorzystane będzie reszyfrowanie pomiędzy domenami Centrala domena dla 6 centralnych węzłów (kwestie wydajnościowe oraz architekturalne) Reszyfrowanie między domenami realizowane będzie przez redundantne i niezależne huby kryptograficzne W labie przetestowano brak wpływu reszyfrowania na szczególnie wrażliwy ruch 38
Architektura systemu - huby kryptograficzne Huby kryptograficzne Wdrożone zostaną 34 rozproszone (po dwa redundantnie w każdym województwie ) huby kryptograficzne, zapewniające reszyfrowanie ruchu Systemu Zintegrowanej Komunikacji między poszczególnymi domenami Huby kryptograficzne będą mogły również terminować klasyczne (IPSec) i mniej klasyczne (np. DMVPN) połączenia od urządzeń niewspierających GETVPN Możliwość reutylizacji tej koncepcji Będzie mogła być wykorzystywana przy obsłudze ruchu w innych VPNach (ale z wykorzystaniem osobnych routerów reszyfrujących) 39
Architektura systemu - huby kryptograficzne Wykorzystanie koni roboczych, czyli ASR1000 Bardzo wydajne CPU na Route Procesorze Bardzo wydajna sprzętowa (ESP) obróbka pakietów oraz szyfrowanie Pełnią funkcję routera usługowego sieci operatora CPU jest już wykorzystywane w sieci na potrzeby Control Plane (route-reflectory dla potrzeb BGP) Reszyfrowanie GETVPN jest funkcją Data Plane dociążając je, efektywnie wykorzystujemy wszystkie komponenty routera 40
Architektura systemu - huby kryptograficzne Hub kryptograficzny jako podwójny GM KS1 VPN Control KS2 Grupy KS Polityka UC1 PE1 VRF: UC1 GM UC1 Hub Crypto Hub Crypto VRF: UC Grupy KS Polityka UC2 PE1 VRF: UC2 PE2 GM UC1 GM UC2 PE2 41
Architektura systemu - serwery kluczy Serwery kluczy 17 KSów, po jednym serwerze kluczy w każdym województwie - zapewniona niezależność geograficzna Każdy KS obsługuje wszystkie konieczne grupy VPN Połączone zostaną logicznie w grupy wspierające się wzajemnie skalowalność i redundancja Połączenie przez COOP (5x KS w grupie centralnej, pozostałe parami nie przekraczamy ograniczenia 8 KS per grupa ) Każdy KS będzie obsługiwał wszystkie grupy w swoje i wszystkie sąsiada Spójność polityk między swoim a sąsiadem 42
Architektura systemu - serwery kluczy Serwery kluczy Każdy GM rejestruje się przede w swoim lokalnym KSie W przypadku awarii lokalnego, rejestruje się u sąsiada Grupy KS-W1 Polityka VPN A Polityka VPN B Polityka VPN Z KS-W1 KS-W2 Grupy KS-W2 Polityka VPN A Polityka VPN B Polityka VPN Z Grupy KS-W2 Polityka VPN A Polityka VPN B Polityka VPN Z GM GM GM GM VPN A Grupy KS-W1 Polityka VPN A Polityka VPN B Polityka VPN Z 43
Architektura systemu - PKI Dla potrzeb szyfrowania SZK wykorzystywana jest jedynie część systemu PKI Wykorzystanie IOS Certificate Authority na dedykowanych do potrzeb PKI niezbyt dużych routerach (w zupełności wystarczą) Hierarchiczna, scentralizowana, niezawodna struktura Root CA (zakopany głęboko pod ziemią) Sub-CA systemu SZK (redundantne, Active-Standby) RA systemu SZK (redundantne, Active-Standby) Dedykowane serwery do publikacji CRL oraz jako magazyny certyfikatów (flashe routerów nie nadają się do trzymania dziesiątek tysięcy plików) Redundancja dzięki IOS CA High Availability Klienci systemu PKI: wszystkie KS oraz wszystkie GM 44
Architektura systemu - PKI Dostęp klientów PKI do systemu protokołem SCEP (Simple Certificate Enrollment Protocol) Klienci PKI mają dostęp tylko i wyłącznie do RA, jest on kontrolowany poprzez firewalle - CA są schowane w głębi sieci Zatwierdzenie certyfikatów na RA zawsze manualne, przez operatora Odpowiednie procedury eksploatacyjne Również dla okresowego re-enrollmentu Magazyn certyfikatów dostępny poprzez TFTP na dedykowanym serwerze (tylko TFTP potrafi w czasie rzeczywistym ściągnąć na router listę wystawionych certyfikatów, rząd wielkości wydajniejszy niż np. FTP) Autoryzacja dostępu do danej grupy na podstawie części pola DN certyfikatu 45
Architektura w działaniu Przykład: sposób dostępu telefonu IP do klastra CUCM w innym województwie 46
Szaleństwo Route-Targetów Ruch między GMami, a KSami NIE JEST kontrolowany firewallami Dostęp GMów do Ksów musi być niezawodny, niezależnie od stanu sieci Wymagana autonomia województw (nie mamy firewalla w każdym węźle) Znajdźcie mi firewalla, który potrafi kontrolować UDP/848, czyli GETVPNowe IKE :-) Wymiana ruchu następuje poprzez przeciekanie na PE prefiksów VPNv4 między odpowiednimi VPNami Loopbacki KSów i GMów muszą się widzieć (ale tylko tych dla odpowiednich domen grup GETVPN i tylko między odpowiednimi województwami) GMy między różnymi VPNami nie mogą się widzieć Podsieci inne niż loopbacki też nie mogą się widzieć Konfiguracja różna w zależności od kategorii danego węzła Proste ACLki zabezpieczające dostęp do KSów 47
Szaleństwo Route-Targetów Odpowiednia konfiguracja eksportu / importu Route-Targetów (statyczne i route-mapy) Tworzy składankę topologii a la hub-and-spoke Skonfigurowane w dużej skali projektu TYLKO dzięki szablonom W pracy operacyjnej dające się zarządzać również ręcznie VRF CONTROLB2 65112:XXXB2 65112:XXX KS VRF UCB2 65112:XXXB2 GK VRF VGB2 65112:XXXB2 VRF ADMIN_B1 65112:XXXB1 65112:XXX VG PFX_UCB1_LOOP 65112:XXXB2 PFX_UCB1_LOOP 65112:XXX11 PFX_UCB1_LOOP 65112:XXXB2 VRF ADMINAX 65112:XXXAX 65112:XXX PFX_CTRB1_KS 65112:XXXB2 PFX_CTRB1_KS 65112:XXXB2 VRF CONTROL_B1 65112:XXXB1 65112:XXX KS VRF UC_B1 65112:XXXB1 VRF VG_B1 65112:XXXB1 GK VG PFX_UCB1 65112:XXXB1 ROUTE MAP PFX_UCB1 65112:XXXB1 PFX_UCB1 65112:XXXB1 PFX_UCB1 65112:XXXB1 ROUTE MAP ROUTE MAP PFX_UCB1 65112:XXXB1 PFX_UCB1 65112:XXXB1 PE1 48
Jak to skonfigurować? Równoważenie obciążenia KS w większej grupie zapewnia konfiguracja GM rejestruje się zawsze do pierwszego skonfigurowanego, działającego KSa Wszystkie GMy w danej grupie mają skonfigurowany ten sam zestaw KSów, ale w różnej kolejności Kolejność KSów w konfiguracji ustalana przez hash numeru węzła lub lokalizacji - takie rzeczy możliwe są tylko dzięki szablonom konfiguracji Użycie do tego celu szablonów konfiguracji generowanych w Excel (zapraszam na moją drugą prezentację podczas PLNOG9) crypto gdoi group GET_UC identity number 2999 server address ipv4 280.390.216.11 server address ipv4 280.390.230.11 server address ipv4 280.390.115.11 server address ipv4 280.390.120.11 server address ipv4 280.390.201.11! konfiguracja GMa m crypto gdoi group GET_UC identity number 2999 server address ipv4 280.390.115.11 server address ipv4 280.390.120.11 server address ipv4 280.390.201.11 server address ipv4 280.390.216.11 server address ipv4 280.390.230.11! konfiguracja GMa n 49
Tak, to działa! Dziękuję! 50