Elektroda.pl
Elektroda.pl
X
Proszę, dodaj wyjątek dla www.elektroda.pl do Adblock.
Dzięki temu, że oglądasz reklamy, wspierasz portal i użytkowników.

RV0xx - Autoryzacja Internetii DHCP i MAC

forsoft 16 Paź 2012 11:14 987 0
  • #1
    forsoft
    Poziom 21  
    Internetia ma rozległą sieć ethernetową na terenie całego miasta podzieloną na podsieci o różnych zakresach adresów i gałęzie spięte zarządzalnymi przełącznikami wymagającymi autoryzacji przez DHCP i MAC. Budynki połączene są ze sobą światłowodami a klienci teoretycznie mogą łączyć się między sobą z prędkością do 100Mbit.

    Mam 3 punkty w mieście połączone siecią VPN. Dwa z nich znajdują się w tej samej podsieci w różnych jej gałęziach, a trzeci w innej podsieci. VPN G2G zbudowany jest na routerach RV042 v1 (1.3.12.19-tm) i RV082 v1 (2.0.2.01-tm). Do sieci VPN wchodzi jeszcze kilka innych punktów znajdujących się jednak poza siecią Internetii. Zmierzona szybkość transferu pliku pomiędzy RV042 i RV082 w tej samej podsieci wynosi nieco ponad 20Mbit.

    Niedawno Internetia wprowadziła autoryzację DHCP i MAC na przełącznikach spinających gałęzie sieci. Teraz kilka razy dziennie przełaczniki blokują ruch do momentu odnowienia adresu IP przez DHCP. Adresy odnawiane są automatycznie co 20 minut, więc powstają stosunkowo krótkie, ale denerwujące przerwy w łączności. Przypuszczam, że jest to spowodowane zmianami w ustawieniach przełączników i ich restartem.

    Routery RV0xx posiadają wbudowaną funkcję wykrywania braku połączenia, ale nie jest ona połączona z automatycznym odnowieniem adresu IP na porcie WAN. Pozwala ona jedynie na wygenerowanie wpisu w logu, lub wyłączenie portu WAN do czasu powrotu łączności. W efekcie router potrafi przekierować połączenia przez drugi port WAN, ale nie stara się naprawić połączenia. W tej samej sytuacji Digitus DN-11005 będący klonem SMC Barricade natychmiast wykrywa utratę pingu do bramy i stara się odnowić adres IP przez DHCP.

    Rozważam więc różne scenariusze poprawiające bieżącą sytuację:

    1. Postawić router potrafiący wykrywać i naprawiać połączenie przed RV042. Wymagałoby to podłączenia RV042 za NAT utrudniając istotnie tworzenie tuneli IPSec VPN.

    2. Przydzielić RV042 stały adres IP i równolegle do niego postawić inny router wykrywający zanik połączenia i odnawiający adres IP. Oba urządzenia muszą mieć ten sam adres MAC na porcie WAN, więc zastosowanie przełącznika sieciowego powoduje zrywanie połączeń w RV042. Stosowanie 10Mbit huba mija się z celem, gdyż powoduje ogromną ilość błędów i retransmisji praktycznie zmniejszających transfer do około 0,1 Mbit. Idealnym łącznikiem byłby hub posiadający funkcję buforowania i obsługujący tryb duplex, lub przełącznik sieciowy przesyłający wszystko w trybie broadcast. Nie posiadam huba 100Mbit więc nie przetestowałem pełnej funkcjonalności tego rozwiązania.

    3. Znaleźć lepsze urządzenie niż RV042. To dość trudne zadanie, gdyż wymagania są dość spore. Już sama wydajność szyfrowania IPSec VPN przekraczająca 20Mbit wymaga wyspecjalizowanego procesora bezpieczeństwa. Jedna z lokalizacji posiada też dwa łącza WAN, więc funkcja dzielenia ruchu przez dwa łącza jest bardzo mile widziana. Na dzień dzisiejszy wystarczający jest limit 8 tuneli IPSec VPN.

    4. Zbudować programowy router na zwykłym komputerze. Niestety nie znam dokładnych wymagań sprzętowych wymaganych do szyfrowania tuneli IPSec VPN. Urządzenia RV0xx najlepiej spisują się z szyfrowaniem 3DES. Zastosowanie tego samego sposobu w połączeniu z procesorem x86 mija się z celem. Trzeba by więc zmienić szyfrowanie na AES. Jeżeli wystarczyłby PIII ok 1GHz to można by taką opcję rozważać. Nie mam jednak doświadczenia z tworzeniem routera na platformie x86.

    Nie mam innych pomysłów. Pozostaje mi czekać na komentarze.