co to jest przepływ ruchu sieciowego?
przepływy ruchu sieciowego (przepływy) są przydatne do budowania gruboziarnistego zrozumienia ruchu w sieci komputerowej, zapewniając wygodną jednostkę do pomiaru i / lub leczenia ruchu.
przepływy można zmierzyć, aby zrozumieć, co mówią hosty w sieci, ze szczegółami adresów, wolumenów i rodzajów ruchu. Ten Widok sieci może być przydatny do rozwiązywania problemów, wykrywania incydentów bezpieczeństwa, planowania i fakturowania
, ale czym dokładnie jest przepływ i jak jest zdefiniowany?
odpowiedź na to pytanie brzmi trywialnie, jednak gdy kopiemy głębiej, znajdujemy niuanse i narożne przypadki, które sprawiają, że przepływy są interesujące, a ostatecznie trudne do zdefiniowania.
Tło
aby naprawdę zrozumieć przepływy, musimy zacząć od jakiegoś tła.
sieci zaczynały się jako przełączane. Gdy host chciał komunikować się z innym hostem, poprosił sieć o skonfigurowanie obwodu. Po zakończeniu przepływu informacji obwód został zburzony.
Rysunek 1-przykład sieć Komutowana
sieci komutowane mają swoje dziedzictwo w sieciach telefonicznych. Mają one wiele wad, w tym słabą skalowalność i niskie wykorzystanie mocy produkcyjnych.
do zbudowania tego, co ostatecznie stało się internetowymi sieciami komutowanymi pakietami, potrzebna była alternatywa. Wiadomości są pocięte na kawałki o zmiennej wielkości, które są indywidualnie adresowane i wysyłane jako pakiety w sieci.
Rysunek 2-przykładowa sieć Komutowana pakietami
host odbierający ponownie składa ładunek z pakietów z powrotem do wiadomości. Uwaga: pakiety mogą również zawierać informacje kontrolne, takie jak kontrola przepływu, a ścieżki nie muszą być symetryczne.
Definiowanie przepływów w sieci z komutacją obwodów jest łatwe, ponieważ obwód jest przepływem i postępuje zgodnie z protokołem w celu ustanowienia i anulowania (circuit = flow); jednak w sieci z komutacją pakietów rzeczy są mniej oczywiste.
wyobraź sobie przez sekundę, że jesteś w punkcie obserwacyjnym a w sieci przełączanej obwodami na rysunku 1, zobaczysz:
Rysunek 3-przybliżenie sieci z przełączaniem obwodów
można zaobserwować dwa przepływy – obwody między hostami 3 & 4 i hostami 5 & 6. Obserwacja przepływów w sieci komutowanej jest stosunkowo łatwa, ponieważ sieć jest zaangażowana w Konfigurowanie obwodów, więc zna ich stan i punkty końcowe.
wyobraź sobie teraz, że jesteś w punkcie obserwacji a w sieci komutowanej pakietami na rysunku 2, zamiast tego zobaczysz:
Rysunek 4-powiększenie sieci z komutacją pakietów
nagle wszystko staje się mniej jasne. Z hosta 5 przychodzi pakiet przeznaczony dla Hosta 6. Zakładając, że obserwujemy przez pewien czas, widzimy więcej pakietów przybywających i odchodzących. Obserwowanie przepływów w sieci komutowanej pakietami wymaga czasu i wymaga rejestrowania i analizowania informacji o pakietach.
pierwsza (naiwna) próba zdefiniowania przepływu
korzystając z naszej wiedzy o sieciach komutowanych pakietami, pierwsza próba odpowiedzi “czym jest przepływ” może być:
przepływ jest sekwencją pakietów przenoszących informacje między dwoma hostami
ta definicja wygląda tak:
Rysunek 5-Pierwsza próba zdefiniowania przepływu
istnieje jednak problem. Co się stanie, jeśli między hostami odbywa się więcej niż jeden rodzaj komunikacji, na przykład A ma połączenie SSH i HTTPS z B? Czy pakiety SSH i HTTPS są częścią tego samego przepływu? Intuicyjnie mówimy nie, są to różne sesje, a nawet zupełnie inne protokoły. Możemy zrobić lepiej …
druga próba zdefiniowania
co powiesz na to, że używamy informacji o Protokole z nagłówków pakietów jako wspólnych właściwości do identyfikacji pakietów w przepływach? Spowoduje to rozdzielenie różnych rodzajów połączeń na różne przepływy.
duża część pakietów w sieci jest prawdopodobnie protokołem IP layer-3, z TCP lub UDP jako protokołem transportowym layer-4. Dlatego rozsądne jest rozważenie użycia parametrów TCP i UDP jako kluczy przepływu z nagłówków pakietów.
użyjemy 5 parametrów z nagłówków pakietów; source IP, destination IP, protocol, TCP lub UDP source port i TCP lub UDP destination port jako uporządkowana lista, powszechnie znana jako 5-krotka, jako wspólne właściwości mapowania pakietów na przepływy.
Rysunek 6-przykład 5-krotka
zaczyna się próba 2:
przepływ jest sekwencją pakietów przenoszących informacje między dwoma hostami, gdzie pakiety mają wspólne właściwości:
- wszystkie pakiety w przepływie mają tę samą 5-krotkę
nasz scenariusz wygląda teraz tak:
Rysunek 7-druga próba zdefiniowania przepływu
Perfect mówisz. Życie jest dobre. Mamy definicję przepływu, nic więcej do zobaczenia … ale poczekaj, a co z kierunkiem pakietów?
trzecia próba – dwukierunkowa
5-krotka jest jednokierunkowa (jednokierunkowa). Domyślnie będzie pasować tylko do pakietów podróżujących w jednym kierunku, ponieważ pakiety w odwrotnym kierunku mają transponowane adresy IP i numery portów, a tym samym inny 5-krotny Skrót.
istnieją dobre powody, aby uważać przepływy za dwukierunkowe, a nie jednokierunkowe, w tym możliwość określania zachowania klienta/serwera i obliczania czasu podróży w obie strony, a także lepsze wykrywanie incydentów bezpieczeństwa, takich jak skanowanie.
rozważ proste połączenie TCP na rysunku 8, gdzie Pakiety odbijają się w tę i z powrotem między hostem a & B:
Rysunek 8-schemat drabinkowy prostego przepływu TCP
widzimy klasyczny TCP 3-way handshake (SYN, SYN+ACK, ACK), po którym następuje wymiana danych. Analiza przepływu jednokierunkowego w punkcie obserwacyjnym sieci pozwoliłaby zobaczyć dwa oddzielne przepływy, po jednym na kierunek, zgodnie z rysunkiem 9:
Rysunek 9-drabiny jednokierunkowe dla prostego przepływu TCP
problem z jednokierunkowym pomiarem przepływu polega na tym, że tracimy możliwość przechwycenia ważnych metadanych dotyczących przepływu. Oczywiście, każdy jednokierunkowy przepływ może przechowywać metadane kierunkowe dla bajtów i pakietów w tym kierunku. Może to obejmować czas między pakietami (patrz kropki oznaczone na rysunku 9). Ale tracimy możliwość zebrania metadanych, które wymagają pomiaru parametrów ruchu w obu kierunkach.
rozważ obserwację dwukierunkową na rysunku 10:
Rysunek 10-Drabinka dwukierunkowych obserwacji dla prostego przepływu TCP
możemy teraz obserwować i mierzyć TCP 3-way handshake (punkty F1, B1, F2) i przyjrzeć się innym metrykom, takim jak czasy odpowiedzi.
dla przepływów dwukierunkowych potrzebujemy dwóch 5 krotek, z których drugi odwraca kolejność krotek zarówno adresów IP, jak i numerów portów. Poniżej znajduje się przykład przepływu SSH do przodu i do tyłu 5-krotek:
Rysunek 11-odwrócenie 5 krotki
racja, to nie było zbyt trudne. Ale czekaj, czai się mały szczegół, który wymaga dalszej uwagi. Skąd wiemy, jaki jest kierunek przepływu do przodu? Ustalamy kierunek na podstawie pierwszego zaobserwowanego pakietu, który zakłada się, że porusza się w kierunku klienta do serwera, ale nie będzie to w 100% wiarygodne, ponieważ pakiety mogą być nie w porządku i/lub obserwacja może rozpocząć się częściowo w przepływie. Użyjemy tej metody, ale musimy pamiętać, kiedy patrzymy na wyniki, że nie jest doskonała.
alternatywną metodą jest kontrola pól protokołu transportowego. Na przykład w TCP obecność tylko flagi SYN jest rozsądnym wskaźnikiem, że pakiet jest pierwszym pakietem w przepływie.
nasza definicja dla przepływu jest teraz:
przepływ jest sekwencją pakietów przenoszących informacje między dwoma hostami, gdzie pakiety mają wspólne właściwości:
- wszystkie pakiety w przepływie mają tę samą 5-krotność lub transponowaną 5-krotność
czwarta próba-w tym ruch IP nie będący TCP
do tego momentu zakładaliśmy, że protokołem transportowym jest TCP. A co z innymi protokołami transportu IP?
UDP jest oczywistym wyborem dla drugiego najczęściej spotykanego protokołu transportowego, zwłaszcza ze wzrostem ruchu w czasie rzeczywistym przez UDP, a także Nowych Protokołów, takich jak QUIC. UDP łatwo pasuje do tego samego modelu, ponieważ ma numery portów źródłowych i docelowych, zgodnie z poniższym przykładem QUIC:
Rysunek 12-odwrócenie protokołu UDP 5-krotnego (takiego samego jak TCP)
Stream Control Transmission Protocol (SCTP) jest kolejnym protokołem transportowym, który używa numerów portów i tym samym współpracuje z 5-krotnym.
ale co z innymi protokołami, na przykład IPsec?
IPsec ESP (Encapsulating Security Payload) jest protokołem, który nie zawiera numerów portów źródłowych/docelowych, więc musimy wrócić do 3-krotności, ponieważ zrozumienie ładunku protokołu jest mało prawdopodobne, aby było praktyczne.
rysunek 13-dwukierunkowa 3-krotka
nasza definicja przepływu jest teraz:
przepływ jest sekwencją pakietów przenoszących informacje między dwoma hostami, gdzie pakiety mają wspólne właściwości:
- dla protokołów transportowych z numerami portów (tj. TCP / UDP / SCTP):
wszystkie pakiety w przepływie mają tę samą 5-krotkę lub transponowane 5-krotkę
else:
wszystkie pakiety w przepływie mają tę samą 3-krotkę lub transponowane 3 – krotkę
jest jednak jeszcze inny czynnik do rozważenia-czas.
piąta próba – wygaśnięcie przepływu
przepływ istnieje tylko przez określony czas. Możliwe jest, że ta sama 5-krotka (lub 3-krotka) może być ponownie użyta w innym momencie, dla innego przepływu, między tymi samymi hostami.
rozważ dwa hosty, gdzie jeden inicjuje wiele nowych połączeń TCP z drugim. Każde nowe połączenie TCP otrzymuje nowy port źródłowy, Zwykle zwiększany o 1 z poprzedniej alokacji. IANA przydziela zakres 49152 do 65535 dla tych efemerycznych portów, dając 16384 porty. Z czasem port źródłowy TCP przetnie się przez Zakres, a oryginalny port źródłowy zostanie ponownie użyty, a ten przepływ będzie miał tę samą pięciostopnię co oryginalny przepływ. Stanowi to problem, ponieważ nie jest to ten sam przepływ!
aby to rozwiÄ … zać, musimy wygasnÄ … Ä ‡ przepĹ ‘ywy, w ktĂłrych pakiety nie sÄ … widoczne przez dĹ’ uĺźszy czas niĹź okreĹ ” lony. I znowu:
przepływ jest sekwencją pakietów przenoszących informacje między dwoma hostami, gdzie pakiety mają wspólne właściwości:
- dla protokołów transportowych z numerami portów (tj. TCP / UDP / SCTP):
wszystkie pakiety w przepływie mają tę samą 5-krotność lub transponowane 5-krotność
else:
wszystkie pakiety w przepływie mają tę samą 3-krotność lub transponowane 3-krotność
- wszystkie czasy między pakietami są mniejsze niż dowolna wartość limitu czasu wygaśnięcia przepływu
szósta próba-dowolne parametry
czasami możesz chcieć, aby różne parametry identyfikowały przepływy, lub mogą być wymuszone przez typ sprzętu / oprogramowania w sieci.
na przykład w routerze Cisco przepływy są identyfikowane przez 7-krotkę, która dodaje typ usługi (tos) i pod-interfejs wejściowy do Standardowej 5-krotki. Mogą się również zdarzyć sytuacje, w których pola warstwy 2, takie jak źródłowy lub docelowy adres MAC, mogą mieć sens jako klucze przepływu (chociaż należy pamiętać, że są one ważne tylko lokalnie).
istnieją inne parametry, które można wykorzystać jako wspólne właściwości do identyfikacji przepływu; ostatecznie decyzja i możliwości urządzenia należy do operatora. Na tej podstawie udoskonalamy definicję:
przepływ jest sekwencją pakietów przenoszących informacje między dwoma hostami, gdzie pakiety mają wspólne właściwości:
- dla protokołów transportowych z numerami portów (tj. TCP / UDP / SCTP):
wszystkie pakiety w przepływie mają tę samą 5-krotkę lub transponowane 5-krotkę
else:
wszystkie pakiety w przepływie mają tę samą 3-krotkę lub transponowane 3-krotkę
- wszystkie czasy między pakietami są mniejsze niż dowolna wartość limitu czasu wygaśnięcia przepływu
- może używać dowolnych parametrów jako kluczy przepływu, w tym ToS, interfejsu itp.
Podsumowując to wszystko
pokazaliśmy, że stworzenie pojedynczej, wszechogarniającej definicji przepływu jest trudnym problemem. Definicja przepływu jest specyficzna dla wdrożenia, zależna od wymagań użytkownika, a także możliwości sprzętu sieciowego, który mierzy przepływy.
w części 2 tego posta na blogu przejdziemy do dalszych rozważań dotyczących przepływów, takich jak etykiety przepływów IPv6, fragmentacja (problem z IPv4 i IPv6..), szyfrowanie, Pakiety inne niż IP oraz sposób pomiaru i wykorzystania przepływów w innych systemach, takich jak SDN.
Zobacz: https://www.eecs.yorku.ca/course_archive/2015-16/W/3214/CSE3214_01_PacketCircuitSwitching_2016_posted_part2.pdf
dla niektórych powiązanych dokumentów, patrz: https://www.researchgate.net/profile/Brian_Trammell/publication/245587221_Bidirectional_Flow_Measurement_IPFIX_and_Security_Analysis/links/0f3175331dd3b49103000000/Bidirectional-Flow-Measurement-IPFIX-and-Security-Analysis.pdf i https://is.muni.cz/th/hilnn/cse2009.pdf
dla odpowiednich RFC, patrz:: https://tools.ietf.org/html/rfc5103
więcej informacji na temat standaryzacji QUIC znajduje się w: https://datatracker.ietf.org/wg/quic/about/
Zobacz: https://www.cisco.com/en/US/tech/tk812/technologies_white_paper09186a008022bde8.shtml
Leave a Reply