bintec VPN5 i bintec X2301

Transkrypt

1 bintec VPN5 i bintec X2301 konfiguracja połączenia IPSec pomiędzy centralą firmy (TP DSL) i oddziałem (Neostrada+Dynamic DNS) Routery Bintec, oprócz rzadkiej elastyczności w postaci obsługi wielu podsieci LAN i łączy WAN, charakteryzują się wyjątkowym podejściem do implementacji IPSec. Niezależnie bowiem od ceny/wydajności/liczby tuneli, wszystkie modele zostały wyposażone w ten sam wachlarz opcji, tworzących najwyższej jakości implementację protokołu IPSec (high-end IPSec). Dotyczy to modeli realizujących 100, 250 i 1000 tuneli, ale także podstawowych modeli SOHO dla linii ADSL, co w przypadku tych ostatnich jest czymś niezwykle rzadkim na rynku. Na ową atrakcyjność składa się uwierzytelnianie podpisem cyfrowym RSA/DSA z wykorzystaniem certyfikatów X.509, szeroki wybór algorytmów szyfrujących, od standardów DES/3DES i AES256, po rzadko implementowane Blowfish, Twofish, CAST itd., oraz opcjonalna kompresja IPCOMP zwiększająca pasmo w tunelu nawet o kilkadziesiąt procent. Uzupełnienie stanowi mechanizm QoS dla zarządzania pasmem VPN, filtrowanie ruchu w sieci VPN, wykorzystanie kilku łączy WAN (Load Balancing) dla VPN. Są to cechy nawet najprostszych modeli Bintec, stanowiące o możliwości ich zastosowania w pojedynczej instalacji oraz w dużym projekcie VPN, gdzie pracują także rozwiązania innych producentów oraz rozwiązania softwareowe. Bintec IPSec oferuje też wyjątkowo dopracowane metody obsługi zmieniających się publicznych adresów IP (Neostrada, ISDN itp.). Jest to rozbudowana implementacja mechanizmów Dynamic DNS oraz dodatkowe opcje uwierzytelniania adresów IP w kanale ISDN (twz. IPSec Callback z wykorzystaniem kanału D lub B). Artykuł pokazuje podstawową konfigurację tunelu IPSec pomiędzy dwoma lokalizacjami firmy. Do dyspozycji mamy: Centrala firmy łącze typu TP DSL ze stałym adresem IP i router Bintec VPN Access 5 Oddział firmy dostęp ADSL typu Neostrada/Net24 i router Bintec X2301/X2302/X2301w/X2302w (zintegrowany modem ADSL) Centrala publiczny, stały adres IP: , maska i brama Oddział publiczny, zmienny adres IP i konto na serwerze DynDNS (nazwa hosta: x2301.dnsalias.com) Centrala prywatny adres LAN routera: / Oddział prywatny adres LAN routera: / Ponadto zakładamy m.in. takie parametry IPSec: Klucz wstępny IKE (Preshared Key): psk (dla testu zaleca się wybrać prosty klucz, jednak docelowo powinien on zawierać co najmniej przypadkowych znaków) Protokół IKE pracuje w trybie agresywnym W obu fazach IKE algorytmy AES/MD-5, protokół ESP, brak kompresji danych tunel może być inicjowany z obu stron (tzn. przez oba routery) na żądanie hosta Uwaga! Artykuł zakłada, że obie lokalizacje posiadają już poprawnie skonfigurowany dostęp do Internetu z włączoną translacją NAT na interfejsie publicznym, oraz prawidłową adresację w sieci LAN (według podanych powyej założeń). W razie problemów należy zatem skorzystać z osobnych artykułów poświęconych konfiguracji dostępu typu Neostrada (X2301/X2301w) i Net24 (X2302/X2302w), jak i DSL TP (VPN Access 5). Aby uzyskać dostęp do konfiguracji, najlepiej zainstalować z płyty CD oprogramowanie BRICKware, podłączyć kabel konsoli pod port COM1 w komputerze i wybrać opcję Start->Programy->BRICKware->Device At COM1. Otworzy się okno domyślnego terminala (np. Hyperterminal) z gotowymi ustawieniami połączenia dla portu konsoli. Naciskamy <Enter> i podajemy parametry 1

2 logowania (fabrycznie login: admin, password: bintec). Uwaga! Do konfiguracji urządzenia można też dostać się terminalem Telnet oraz przeglądarką http (domyślny adres IP: , login: admin/password: bintec). Komputer musi w tym celu posiadać odpowiedni adres z podsieci /24, np Adres należy przypisać statycznie, gdyż serwer DHCP nie jest aktywny domyślnie. Przed przystąpieniem do dalszej konfiguracji należy koniecznie zadbać o to, aby routery posiadały najnowsze oprogramowanie systemowe. Weryfikacji wersji oprogramowania dokonujemy komendą swversion: Uwaga! Najnowsze wersje oprogramowania wraz z opisem procesu aktualizacji można uzyskać w serwisie producenta Np. niniejszy opis zakłada, że router X3301 posiada oprogramowanie 7.2 Rev. 2 Patch 1 z dnia , oraz aktualny plik Country Profiles (szczegóły w serwisie producenta). Router X2301/X konfiguracja połączenia IPSec Po zalogowaniu wywołujemy pseudo-graficzny program konfiguracyjny poleceniem setup + <Enter> i przechodzimy do konfiguracji połączenia IPSec: Uwaga! Jeżeli w menu głównym konfiguratora nie występuje pozycja IPSec, może to oznaczać brak odpowiedniej licencji. Darmowa licencja na 2 tunele jest zawarta w oprogramowaniu, należy tylko zadbać o wgranie odpowiedniej jego wersji do routera X2301/X2302 ( Jeżeli po wybraniu opcji IPSec router nie uruchomi specjalnego kreatora konfiguracji IPSec, uruchamiamy go ręcznie wybierając opcję Wizard wewnątrz menu IPSec. Odpowiadamy Yes na pytanie o uruchomienie kreatora. Ustawiamy spacją opcję start wizard i zatwierdzamy <Enter>: 2

3 Zatwierdzamy Preshared Key jako metodę uwierzytelniania (Enter): Wybieramy lokalny identyfikator dla tunelu. W przykładzie wpisujemy nazwę DynDNS routera. Naciskamy <Enter>. Uwaga! Zakładamy, że router posiada poprawnie skonfigurowanego klienta Dynamic DNS dla nazwy FQDN X2301.dnsalias.com (konto u providera DynDNS Po fazie konfiguracji wstępnej kreator rozpoczyna się proces konfiguracji danych związanych z drugą stroną połączenia: Naciskamy Enter i przechodzimy do definicji parametrów określających stronę odległą: Description: stanowi dowolny opis (przydatne, kiedy posiadamy wiele połączeń) Peer Address: oficjalny, publiczny adres IP odległego routera VPN-5. Jeżeli druga strona nie posiada stałego IP ani nazwy DynDNS, musimy tutaj wpisać celem zaakceptowania każdego adresu źródłowego podczas inicjacji. Pole Peer Address może tez zawierać nazwę DNS routera odległego, jeżeli jest ona skonfigurowana w systemie DNS/Dynamic DNS. Peer IDs: musi być zgodne z wpisem Local ID dla odpowiedniego profilu połączenia w routerze zdalnym Pre Shared Key: zaleca się w fazie testu użyć prostego słowa, np. psk, jednak po poprawnym uruchomieniu połączenia należy koniecznie zmienić na ciąg długości min przypadkowych znaków. Postać klucza musi być identyczna w obu routerach, inaczej pierwsza faza IKE zakończy się błędem autoryzacji. Dlatego klucz musimy wpisać dwa razy celem weryfikacji i wykluczenia pomyłki. Virtual Interface: tutaj określamy podstawową zasadę, według której selekcjonowany będzie ruch podlegający wynegocjowanym zabezpieczeniom SA dla tego właśnie tunelu IPSec. W przykładzie posługujemy się ideą wirtualnego interfejsu. Tunel IPSec jest tu traktowany jako wirtualny interfejs WAN z własnym adresem IP, i może brać udział w routingu/translacji NAT itp. tak jak interfejs fizyczny. Zatem decyzja o zaszyfrowaniu pakietu zachodzi po stwierdzeniu na poziomie routingu, że pakiet musi zostać wysłany przez dany interfejs WAN gdyż jest przeznaczony do sieci /24, osiągalnej właśne poprzez ten interfejs (patrz dalej). Rezygnacja z opcji Virtual Interface wymusza użycie innej koncepcji wyznaczania ruchu w tunelu, koncepcji filtrowania ruchu. Tworzy się wówczas reguły filtru, z adresami źródłowymi/docelowymi, portami itd. Jest to metoda starsza i rzadko stosowana w trybie tunelu. Wybieramy Yes i zapisujemy całość SAVE. Ponieważ wybraliśmy wirtualny interfejs IP, kreator proponuje jego konfigurację. Zatwierdzamy Enter. 3

4 Stajemy przed wyborem opcji podstawowych i zaawansowanych. Wybieramy Basic IP-Settings: Ponieważ tunel będzie reprezentowany przez oddzielny interfejs IP, wymagana jest jego konfiguracja, oraz konfiguracja routingu do sieci zdalnej przez ten interfejs: Remote IP Address/ Netmask: jest definicją statycznej trasy dodawanej do tabeli routingu, i informującej router że dana podsieć jest osiągalna przez wirtualny interfejs stworzony dla reprezentacji tunelu. Każdy pakiet, który jest przesyłany przez interfejs podlega wynegocjowanym zasadom ochrony IPSec, jednak najpierw zachodzi decyzja odnośnie routingu. Dlatego podajemy tutaj adres odległej podsieci, z którą zamierzamy się połączyć dla uzyskania routingu przez tunel. Po zapisaniu zmian SAVE, przechodzimy do ostatniego kroku kreatora. Naciskamy Enter aby pominąć zapisanie raportu kreatora (zatwierdzamy polecenie dump messages): Ostatecznie opuszczamy kreator unikając jego ponownego uruchomienia przechodzimy strzałką do pozycji EXIT i naciskamy Enter: 4

5 Resztę konfiguracji wykonujemy ręcznie. W menu odpowiadającym IPSec wybieramy opcję Configure Pers. Na liście skonfigurowanych połączeń odnajdujemy stworzony przez nas profil o nazwie to_dsl i po jego zaznaczeniu naciskamy <Enter>: W ramach ustawień konkretnego połączenia wybieramy Peer specific settings i przechodzimy do obszaru pozwalającego przypisywać do bieżącego tunelu indywidualne profile zabezpieczeń. Można wykorzystać profile stworzone automatycznie przez kreator, bądź tworzyć własne, odpowiadające indywidualnym preferencjom dla danego tunelu. Profile zabezpieczeń to zbiory szczegółowych parametrów, predefiniowane osobno dla obu faz protokołu IKE. Po stworzeniu, mogą być wykorzystywane przez jeden lub wiele niezależnych tuneli wymagających wspólnej polityki zabezpieczeń. Router przechowuje dwie globalne listy profili dla obu faz IKE. Wchodzimy kolejno na obie listy (oznaczone dalej różnymi kolorami), aby wykreować własne profile IKE. Na liście dla fazy 1 IKE (kolor czerwony) wybieramy ADD celem dodania nowego profilu zabezpieczeń. 5

6 Wybieramy parametry dla 1 fazy IKE: szyfrowanie AES/autentykacja MD- 5 grupa wymiany DH: 2 metoda uwierzytelniania: preshared key tryb IKE: aggressive only włączamy Heartbeats (mechanizm Dead Peer Detection opracowany dla routerów Bintec) Local ID: nazwa FQDN routera Nat-Traversal: wyłączamy włączone oznacza dodatkowe tunelowanie z wykorzystaniem UDP pozwalające pokonać ograniczenia związane z translacją NAT pomiędzy końcami tunelu Zatwierdzamy zmiany SAVE. Nowo zdefiniowany profil o wybranej nazwie pojawia się na liście profili dla 1 fazy IKE. Opuszczamy listę wybierając EXIT. Znajdując się na powrót w menu Peer Specific Settings, wybieramy listę profili dla drugiej fazy IKE (kolor zielony). 6

7 Podobnie jak wyżej, wybieramy ADD: Wybieramy parametry dla 2 fazy IKE: Protokół ESP, szyfrowanie AES i autentykacja MD-5 PFS z grupą DH: 2 włączamy Heartbeats dla obu kierunków (mechanizm Dead Peer Detection opracowany dla routerów Bintec) Propagate PMTU pozwalamy na działanie mechanizmu wykrywania MTU ścieżki przez systemy operacyjne Zapisujemy (SAVE), po czym opuszczamy listę (EXIT) powracając do menu Peer specific settings. Uwaga! Nazwa Rijndael to w systemie operacyjnym Bintec oznaczenie algorytmu AES (Advanced Encryption Standard). Nazwa ta pochodzi od twórcy algorytmu, i jest konsekwencją jego wczesnego zaimplementowania w routerach Bintec (skrót AES powstał później). Uwaga! Opcja Edit Lifetimes pozwala zdefiniować indywidualne warunki renegocjacji dla kluczy w obu fazach IKE, zarówno na podstawie upływu czasu jak i ilości danych przesłanych w tunelu. W przykładzie stosowano zasady domyślne. Po wygenerowaniu własnych profili dla obu faz IKE i umieszczeniu ich na globalnych listach, możemy skojarzyć nasze profile z konfigurowanym tunelem. Powracamy do menu Peer specific settings i strzałkami klawiatury dla obu faz IKE ustawiamy stworzone przez nas profile (nazwa, jaka nadaliśmy pojawia się w polu kursora). 7

8 Po ustawieniu strzałkami wybranych profili, przechodzimy na pole SAVE i naciskamy Enter. Następuje powrót o poziom wyżej do menu głównego związanego z danym połączeniem IPSec. Wybieramy SAVE aby zapamiętać wszystkie skojarzenia profili. Na liście profili połączeń wybieramy EXIT i przechodzimy do głównego menu IPSec: Tutaj ostatecznie zapisujemy wszystkie zmiany dokonane podczas konfiguracji tunelu. W menu głównym konfiguratora Setup Tool wybieramy EXIT. 8

9 Na pytanie czy zapisać zmiany do konfiguracji startowej, odpowiadamy twierdząco. Router VPN Access 5 - konfiguracja połączenia IPSec Po zalogowaniu wywołujemy pseudo-graficzny program konfiguracyjny poleceniem setup + <Enter> i przechodzimy do konfiguracji połączenia IPSec: Uwaga! Routery z rodziny VPN Access posiadają darmową i nierozszerzalną licencję na 5, 25, 100, 250 lub 1000 tuneli IPSec, w zależności od modelu. Jest to niezależne od wersji oprogramowania. Jeżeli po wybraniu opcji IPSec router nie uruchomi specjalnego kreatora konfiguracji IPSec, uruchamiamy go ręcznie wybierając opcję Wizard wewnątrz menu IPSec. Odpowiadamy Yes na pytanie ouruchomienie kreatora: Ustawiamy spacją opcję start wizard i zatwierdzamy <Enter>: 9

10 Zatwierdzamy Preshared Key jako metodę uwierzytelniania (Enter): Wybieramy lokalny identyfikator dla tunelu. W przykładzie wpisujemy ciąg znaków vpn5. Naciskamy <Enter>. Uwaga! Identyfikator nie musi mieć postaci nazwy DNS/Dynamic DNS. Tym bardziej, że router posiada stały adres IP i nie korzysta z systemu DNS/DynDNS - nie ma przypisanej publicznej nazwy hosta DNS.. Po fazie konfiguracji wstępnej kreator rozpoczyna się proces konfiguracji danych związanych z drugą stroną połączenia: Naciskamy Enter i przechodzimy do definicji parametrów określających stronę odległą: Description: stanowi dowolny opis (przydatne, kiedy posiadamy wiele połączeń) Peer Address: oficjalny, publiczny adres IP odległego routera. Jeżeli druga strona nie posiada stałego IP ani nazwy DynDNS, musimy tutaj wpisać celem zaakceptowania każdego adresu źródłowego podczas inicjacji. Pole Peer Address może tez zawierać nazwę DNS routera odległego, jeżeli jest ona skonfigurowana w systemie DNS/Dynamic DNS. Pozwala to nie tylko zezwalać na inicjowanie tunelu przez zdalny router, ale też inicjować w kierunku do zdalnego routera. Peer IDs: musi być zgodne z wpisem Local ID dla odpowiedniego profilu połączenia w routerze zdalnym Pre Shared Key: zaleca się w fazie testu użyć prostego słowa, np. psk, jednak po poprawnym uruchomieniu połączenia należy koniecznie zmienić na ciąg długości min przypadkowych znaków. Postać klucza musi być identyczna w obu routerach, inaczej pierwsza faza IKE zakończy się błędem autoryzacji. Dlatego klucz musimy wpisać dwa razy celem weryfikacji i wykluczenia pomyłki. Virtual Interface: tutaj określamy podstawową zasadę, według której selekcjonowany będzie ruch podlegający wynegocjowanym zabezpieczeniom SA dla tego właśnie tunelu IPSec. W przykładzie posługujemy się ideą wirtualnego interfejsu. Tunel IPSec jest tu traktowany jako wirtualny interfejs WAN z własnym adresem IP, i może brać udział w routingu/translacji NAT itp. tak jak interfejs fizyczny. Zatem decyzja o zaszyfrowaniu pakietu zachodzi po stwierdzeniu na poziomie routingu, że pakiet musi zostać wysłany przez dany interfejs WAN gdyż jest przeznaczony do sieci /24, osiągalnej właśne poprzez ten interfejs (patrz dalej). Rezygnacja z opcji Virtual Interface wymusza użycie innej koncepcji wyznaczania ruchu w tunelu, koncepcji filtrowania ruchu. Tworzy się wówczas reguły filtru, z adresami źródłowymi/docelowymi, portami itd. Jest to metoda starsza i rzadko stosowana w trybie tunelu. Wybieramy Yes i zapisujemy całość SAVE. 10

11 Ponieważ wybraliśmy wirtualny interfejs IP, kreator proponuje jego konfigurację. Zatwierdzamy Enter. Stajemy przed wyborem opcji podstawowych i zaawansowanych. Wybieramy Basic IP-Settings: Ponieważ tunel będzie reprezentowany przez oddzielny interfejs IP, wymagana jest jego konfiguracja, oraz konfiguracja routingu do sieci zdalnej przez ten interfejs: Remote IP Address/ Netmask: jest definicją statycznej trasy dodawanej do tabeli routingu, i informującej router jaka podsieć jest osiągalna przez wirtualny interfejs stworzony dla reprezentacji tunelu. Dlatego podajemy tutaj adres odległej podsieci LAN, obsługiwanej przez zdalny router X2301. Po zapisaniu zmian SAVE, przechodzimy do ostatniego kroku kreatora. Naciskamy Enter aby pominąć zapisanie raportu kreatora (dump messages). Ostatecznie opuszczamy kreator unikając jego ponownego uruchomienia przechodzimy strzałką do pozycji EXIT i naciskamy Enter: Resztę konfiguracji wykonujemy ręcznie. W menu odpowiadającym IPSec wybieramy opcję Configure Pers. 11

12 Na liście skonfigurowanych połączeń odnajdujemy stworzony przez nas profil o nazwie to_dsl i po jego zaznaczeniu naciskamy <Enter>: W ramach ustawień konkretnego połączenia wybieramy Peer specific settings i przechodzimy do obszaru pozwalającego przypisywać do bieżącego tunelu indywidualne profile zabezpieczeń. Można wykorzystać profile stworzone automatycznie przez kreator, bądź tworzyć własne, odpowiadające indywidualnym preferencjom dla danego tunelu. Profile zabezpieczeń to zbiory szczegółowych parametrów, predefiniowane osobno dla obu faz protokołu IKE. Po stworzeniu, mogą być wykorzystywane przez jeden lub wiele niezależnych tuneli wymagających wspólnej polityki zabezpieczeń. Na liście dla fazy 1 IKE (kolor czerwony) wybieramy ADD celem dodania nowego profilu zabezpieczeń: Router przechowuje dwie globalne listy profili dla obu faz IKE. Wchodzimy kolejno na obie listy (oznaczone dalej różnymi kolorami), aby wykreować własne profile IKE. 12

13 Wybieramy parametry dla 1 fazy IKE, odpowiednio do profilu w routerze odległym: szyfrowanie AES/autentykacja MD-5 grupa wymiany DH: 2 metoda uwierzytelniania: preshared key tryb IKE: aggressive only włączamy Heartbeats (mechanizm Dead Peer Detection opracowany dla routerów Bintec) Local ID: vpn5 Nat-Traversal: wyłączamy włączone oznacza dodatkowe tunelowanie z wykorzystaniem UDP pozwalające pokonać ograniczenia związane z translacją NAT pomiędzy końcami tunelu Zatwierdzamy SAVE. Nowo zdefiniowany profil o wybranej nazwie pojawia się na liście profili dla 1 fazy IKE. Opuszczamy listę wybierając EXIT. Znajdując się na powrót w menu Peer Specific Settings, wybieramy listę profili dla drugiej fazy IKE (kolor zielony). 13

14 Podobnie jak wyżej, wybieramy ADD: Wybieramy parametry dla 2 fazy IKE, odpowiednio do profilu w routerze odległym: Protokół ESP, szyfrowanie AES i autentykacja MD-5 PFS z grupą DH: 2 włączamy Heartbeats dla obu kierunków (mechanizm Dead Peer Detection opracowany dla routerów Bintec) Propagate PMTU pozwalamy na działanie mechanizmu wykrywania MTU ścieżki przez systemy operacyjne Zapisujemy SAVE. Po wygenerowaniu własnych profili dla obu faz IKE i umieszczeniu ich na globalnych listach, możemy skojarzyć nasze profile z konfigurowanym tunelem. Powracamy do menu Peer specific settings i strzałkami klawiatury dla obu faz IKE ustawiamy stworzone przez nas profile (nazwa, jaka nadaliśmy pojawia się w polu kursora). 14

15 Po ustawieniu strzałkami wybranych profili, przechodzimy na pole SAVE i naciskamy Enter. Następuje powrót o poziom wyżej do menu głównego związanego z danym połączeniem IPSec. Wybieramy SAVE aby zapamiętać wszystkie skojarzenia profili. Na liście profili połączeń wybieramy EXIT i przechodzimy do głównego menu IPSec: Tutaj ostatecznie zapisujemy wszystkie zmiany dokonane podczas konfiguracji tunelu. W menu głównym konfiguratora Setup Tool wybieramy EXIT. Na pytanie czy zapisać zmiany do konfiguracji startowej, odpowiadamy twierdząco. 15

16 Diagnostyka połączenia Maszyny w sieciach LAN w obu lokalizacjach konfigurujemy według schematu: IP: x, maska , brama IP: x, maska , brama Można też uaktywnić serwer DHCP z pulą adresów w ramach podsieci LAN. Należy też pamiętać, że dla uzyskania dostępu do Internetu konieczna jest usługa DNS. Zatem albo wskażemy adresy serwerów DNS operatora na każdym komputerze ręcznie, albo wpiszemy je w konfigurację routera i przydzielimy dynamicznie w ramach konfiguracji puli DHCP. Inna opcja to użycie routera jako serwera Proxy DNS (caching server) i wskazanie komputerom adresu routera jako podstawowego serwera DNS. Sama diagnostyka polega na wykonaniu komendy ping na adres IP leżący w odległej podsieci LAN. Zaczynamy od upewnienia się, że nasz komputer posiada komunikację z lokalnym routerem-bramą (ping ). Następnie komendą ipconfig upewniamy się, że komputer posiada prawidłowy adres bramy ( ) i wykonujemy komendę ping na adres routera odległego ping Jeszcze lepszym testem jest wykonanie komendy ping na adres wewnętrzny routera zdalnego, będąc zalogowanym na konsoli routera lokalnego. Przy domyślnej konfiguracji firewall routery powinny prawidłowo przekazywać ruch ICMP wewnątrz tunelu, łącznie z pobudzeniem mechanizmu routingu na żądanie i wymuszeniu inicjacji tunelu. Szczegółowa diagnostyka połączenia IPSec sięga poza zakres artykułu, ponieważ ze względu na złożoność tego protokołu nie jest możliwe skomentowanie możliwych objawów i ich przyczyn. Dla osób posiadających odpowiednią wiedzę polecić można komendę debug ipsec dostępną w konsoli oraz monitorowanie szczegółów połączenia za pomocą SysLog. W ramach Setup Tool i skryptu konfiguracyjnego HTTP, w menu IPSec do dyspozycji mamy zawsze opcję Monitoring. Menu to umożliwia śledzenie stanu połączeń Spiec i ręczne usuwanie skojarzeń SA dla obu faz IKE (tzw. IKE SA oraz IPSec SA). Uwaga! Przy włączonej na obu routerach opcji Heartbeat, tunel powinien podlegać automatycznej renegocjacji w sytuacji chwilowej utraty połączenia z Internetem przez któryś z routerów, lub też zmiany adresu IP na Neostradzie. Warto jednak podkreślić, że natychmiastowe odbudowanie tunelu jest możliwe tylko w kierunku Neostrada->DSL (tzn. kiedy router X2301 zamierza wysłać pakiet do sieci za routerem VPN5). Powinno to nastąpić w kilka sekund po przywróceniu dostępu do Internetu. Natomiast w kierunku przeciwnym (router VPN5 inicjuje do X2301) reinicjacja może się wiązać z opóźnieniem większym (do kilku minut, jeżeli wcześniej nie dojdzie do inicjacji ze strony X2301). Jest to normalne, ponieważ router VPN5 nie dysponuje jeszcze poprawnym adresem DNS routera X2301 po zmianie IP router VPN5 musi wykonać szereg kwerend DNS zanim zmiana zostanie zaktualizowana przez router X2301 i rozpropagowana w systemie DNS. Problem ten jest w praktyce rzadko dokuczliwy, przy stabilnym dostępie Neostrada niemal niezauważalny (zmiana IP jest wymuszana raz na dobę). Efekt niespodziewanej przerwy można dodatkowo zminimalizować do kilkunastu sekund wymuszając niewielki ruch (np. ping) z oddziału (Neostrada) do centrali (adres stały). Można tu wykorzystać skrypt systemowy, który uruchamia narzędzie ping okresowo (co kilka sekund) na adres zdalny, wymuszając natychmiastową reinicjację tunelu przez router X2301 w kierunku adresu stałego. Dzięki temu oddział będzie zawsze osiągalny dla centrali bez opóźnień wprowadzanych przez mechanizmy DNS. Umożliwia to bezproblemową pracę mechanizmów sieciowych typu replikacja baz danych i zdalny monitoring czy dostęp do plików. Funkwerk Enterprise Communications GmbH Krakowskie Przedmieście 47/ Warszawa Telefon Faks funkwerk@funkwerk-ec.pl 16