Masz kłopoty z WAN? Spróbuj spoofing'u.

Protokoły sieciowe lubią rozmawiać. Stale wysyłają pakiety tam i z powrotem, wypełnione różnego rodzaju informacją. Tylko część z nich zawiera dane przekazane przez użytkownika. Większość użytkowników nie jest świadoma tego, że znaczna część ruchu w sieci LAN poświęcona jest funkcjom związanym z zarządzaniem protokołami.

Protokoły sieciowe lubią rozmawiać. Stale wysyłają pakiety tam i z powrotem, wypełnione różnego rodzaju informacją. Tylko część z nich zawiera dane przekazane przez użytkownika. Większość użytkowników nie jest świadoma tego, że znaczna część ruchu w sieci LAN poświęcona jest funkcjom związanym z zarządzaniem protokołami.

Prawie wszystkie protokoły sieciowe tracą czas na wysyłanie i odbiór pakietów przeznaczonych do celów zarządzania. Natura owych pakietów jest różna w zależności od rodzaju protokołu. Wiele protokołów wysyła wiadomości typu "utrzymuj kontakt" (keep-alive) do urządzeń w sieci, aby upewnić się czy są one obecne i gotowe do działania. Inne krążą w sieci niosąc informacje o tym w którym miejscu znajdują się urządzenia i w jaki sposób można do nich dotrzeć. Informacje te są zapamiętywane w tablicach tras sieci. Są one regularnie dostarczane uaktualniając zawartość tablic.

Protokół sieci LAN decyduje, jak często są wysyłane wiadomości typu "utrzymaj kontakt" czy uaktualniające tablice tras. Pewne protokoły wysyłają informacje raczej rzadko - co kilka minut lub kilka razy na godzinę. Inne są bardziej agresywne i wysyłają je co kilka sekund. Dla przykładu, Apple Talk wysyła protokoł RTMP (Routing Table Maintenance Protocol) co 10-15 s. Dla użytkownika sieci ruch ten jest praktycznie bez znaczenia, podczas gdy dla inżyniera sieciowego przedstawia dużą wartość. Pakiety zarządzające mocno obciążają sieć, reprezentując ten rodzaj obciążenia, którego użytkownik nie jest świadomy, ale bez którego nie będzie on mógł uzyskać pewnie działającego połączenia.

Pakiety protokołu zarządzającego LAN zwiększają po prostu obciążenie tej sieci. Pasmo przenoszenia sieci lokalnych jest na tyle szerokie, że dodatkowe pakiety zarządzania są rzadko zauważalne. Inaczej rzecz się ma, gdy rozpatrujemy WAN. Ponadplanowo dodany protokół do "normalnego" obciążenia sieci może przyczynić się do jej nasycenia i spowolnić jej działanie, w szczególności powodując utratę szybkości na łączach WAN.

Jest jeszcze inny problem, bardziej złożony. W przeciwieństwie do sieci LAN, w których transmisja danych odbywa się w obrębie jednego miejsca, łącza WAN są zwykle zorientowane na nawiązanie logicznego połączenia korzystając z usług telekomunikacyjnych. Przyłącza wykorzystują cyfrowe linie komutowane, a koszty obsługi połączenia rozliczane są według ogólnie przyjętych zasad. Z tego też powodu łącza WAN są projektowane tak, aby łączność była nawiązywana tylko w momencie przesyłania informacji do odległego miejsca.

Teoretycznie, komutowane przyłącza WAN są oszczędne, ponieważ nie jest pobierana opłata za połączenie w okresie braku przesyłu informacji. Oszczędności te mogą być znaczne. Przypuśćmy, że użytkownik zafunduje sobie przerwę w pracy na stacji roboczej. Czas przestoju może przeciągnąć się od kilku minut do kilku godzin. Ponieważ informacja nie jest w tym czasie przesyłana, to nie ma połączenia i tym samym opłata jest zredukowana do zera. W rzeczywistości protokół dokonuje połączenia za każdym razem, gdy przesyła informacje o uaktualnieniu tras lub typu "utrzymuj kontakt". Stwarza to ryzyko ponoszenia kosztów za opłaty połączeń wówczas, kiedy użytkownik nie jest podłączony. Urządzenia WAN wnoszą dodatkowe koszty, związane z regularną wymianą informacji dotyczącą ich wewnętrznych tablic przebiegu tras.

Potencjalne rozwiązanie tego problemu związane jest z procesem, który nosi angielską nazwę spooofing (oszukiwanie poprzez nadawanie fałszywych informacji). Spoofing umieszcza WAN w modzie utajnionym, w którym urządzenia sieciowe WAN, takie jak pomosty czy routery prowadzą wymianę informacji z odległymi urządzeniami.

Przykładowo, jeżeli plikowy serwer sieci Novell wysyła pakiet SAP (Service Advertising Protocol), wówczas nadająca strona urządzenia WAN nie wywoła strony odległej aby go przesłać. Zamiast tego robi rzecz zupełnie odwrotną - potwierdza odbiór SAP przez odległy LAN. To oszukuje serwer, który wierzy, że odległa sieć jest ciągle podłączona, podczas gdy w rzeczywistości połączenie jest przerwane i użytkownik odłączony.

Zastosowanie techniki spoofing'u jest tematem na czasie wśród producentów WAN. Chociaż jest to całkiem nowa koncepcja rozwiązania sieci WAN, to nie jest to całkiem nowy temat. Pewna odmiana spoofing'u jest czasami używana z protokołem SNA firmy IBM. Protokoł SNA był początkowo używany do zapewienia komunikacji mainframów IBM z odległymi terminalani synchronicznymi.

Jedną z cech SNA jest stałe utrzymywanie połączenia między urządzeniami. W liniach dzierżawionych lub komutowanych podporządkowanie nadrzędny/podległy realizowane jest między urządzeniem sterującym transmisją a jednostką odległą. Niektórzy producenci biorą to pod uwagę projektując urządzenia komunikacyjne SNA.

Aby oszukać SNA, strona sterująca transmisją urządzenia automatycznie odpowiada na pytania dotyczące stanu terminala. W tym czasie zdalna strona urządzenia transmisyjnego udziela odpowiedzi stronie sterującej. Obie strony są zadowolone, chociaż faktycznie nie ma odpowiedzi z odległego miejsca. Obciążenie łącza szeregowego jest zminimalizowane, dając tym samym zwiększenie zdolności przepustowej dla danych użytkownika.

SNA używa odmiennej taktyki w sieciach LAN. Protokół wysyła wiadomość typu "utrzymuj kontakt" lub "czy tam jeszcze jesteś" co 5-10 s. To kwalifikuje go, aby był on traktowany tak samo jak inne protokoły LAN.

Spoofing próbuje oszukać sieć w "myśleniu", że odległe urządzenia nie mające połączenia są połączone. Technika ta bierze górę nad zdolnością systemu sieciowego do zapewniania samego siebie, że wszystko jest w porządku. Każdy system sieciowy jest projektowany w ten sposób i bardzo słusznie. Spooofing nie powinien być źródłem nieprzewidzianych kłopotów, które może napotkać użytkownik czy system sieciowy w związku z jego stosowaniem. Sieć może być oszukiwana do czasu, kiedy informacje dotyczące zarządzania powinne być przesłane. Może to trwać maksimum kilka minut, ale i całą dobę. Trudno jest określić jak długo powinien trwać spoofing.

Oto inne poważne problemy, które niesie spoofing. Protokoły sieciowe wysyłają wiadomości typu "utrzymaj kontakt", aby potwierdzić czy urządzenia są obecne i gotowe do działania. Co jednak się stanie, kiedy rzeczywiście coś się przytrafi odległemu urządzeniu, jak nie ma połączenia? Może ono się popsuć, zrebootować, zawiesić lub odłączyć od zasilania. Nieważne, który z powyższych przypadków zaistnieje, urządzenie nie powróci do stanu poprzedniego. Oszukany w danej chwili system sieciowy nie zdaje sobie sprawy, że stacja sieciowa nie pracowała. Fakt, że może być ona podłączona ponownie w inny sposób niż to jest oczekiwane przez system sieciowy, prowadzi do miliarda potencjalnych problemów. Jest to szczególnie niebezpieczne dla użytkowników serwerów plikowych. Mogą oni przedwcześnie zakończyć pracę w sieci będąc logowanymi przez system po raz wtóry na skutek przerwania połączenia.

Oto inny przykład na to co może się stać, kiedy dwie sieci LAN są ze sobą zdalnie połączone, ale w danym momencie nie mają rzeczywistego połączenia. Topologia jednej z sieci może ulec zmianie w okresie, kiedy użytkownik nie przesyła informacji i nie ma połączenia. Przypuśćmy, że użytkownik wyłączył stację roboczą bądź przeniósł ją z jednego segmentu sieci do drugiego. System sieciowy, gdzie działa spoofing jest nieświadomy tych zmian. Jego tablica tras zawiera ustalenia dla starej topologii. Przypuśćmy z kolei, że dane użytkownika spowodowały podłączenie się odległego LAN-u. W trakcie kolejnego uaktualniania zawartości tablicy tras, Dwie sieci nagle stają przed faktem, że ich tablice różnią się. System sieciowy jest zmuszony podjąć decyzję, która tablica tras odpowiada rzeczywistej topologii sieci, a która jest przestarzała?

Niektórzy twórcy systemów sieciowych, zamiast wprowadzania techniki spoofing'u, prowadzą prace nad tym w jaki sposób obsługiwać wiadomości typu "utrzymaj kontakt" oraz uaktualniające trasy. Większość protokołów LAN została napisana, kiedy połączenia sieci LAN były rzadkością. Projektanci nie rozważali wówczas możliwości podłączenia wszystkich urządzeń w sieci do jednego kabla, a raczej byli pochłonięci opóźnieniami powstającymi we wzmacniaku.

Sieci WAN, w obecnej dobie, są znacznie bardziej powszechne. Być może nadszedł już czas na przepisanie protokołów LAN na protokoły WAN dla połączeń komutowanych. Chociaż jest o wiele prościej coś powidzieć aniżeli zrobić, to jednak daje się ostatnio zauważyć ożywienie w tej dziedzinie. Firmy Apple, Novell i Microsoft już od jakiegoś czasu pracują nad wprowadzeniem technologii WAN do sieciowych protokołów. Jest to jednak proces bardzo skomplikowany i wymagający czasu. Tym niemniej pierwszy krok został już zrobiony.


TOP 200