TCP a inne protokoły

Ponieważ TCP jest protokołem połączeniowym, łatwo w nim pośredniczyć narzut związany z użyciem serwera proxy występuje tylko raz, a potem wystarczy kontynuować to połączenie. W UDP nie ma pojęcia połączenia każdy pakiet jest oddzielną transakcją, wymagającą podjęcia oddzielnej decyzji przez serwer proxy. Łatwiej zatem pośredniczyć w ruchu TCP (choć istnieją serwery proxy dla UDP). Podobnie, trudno pośredniczyć w ruchu ICMP, ponieważ każdy pakiet jest oddzielną transakcją. Pośredniczenie w ICMP jest trudniejsze niż w TCP, ale nie niemożliwe istnieją serwery proxy dla ICMP.

Sytuacja wygląda podobnie z punktu widzenia filtrów pakietów. Dość łatwo przepuścić TCP przez firewall i kontrolować kierunek, w którym są nawiązywane połączenia możesz filtrować pakiety według bitu ACK, aby pozwolić na nawiązywanie połączeń tylko wewnętrznym klientom, przepuszczając zarazem odpowiedzi. W przypadku UDP i ICMP nie jest to tak łatwe. Jeśli użyjesz stanowych filtrów pakietów, możesz przepuszczać pakiety, które wydają się odpowiedziami, ale nigdy nie masz pewności, czy pakiet rzeczywiście jest odpowiedzią na wcześniejszy,

i możesz oczekiwać odpowiedzi na pakiety, które ich nie wymagają. Jedno połączenie na sesję. Firewall może łatwo przechwytywać wstępne połączenia od klienta do serwera, ale trudniej mu przechwycić połączenia zwrotne. Jeśli posługujesz się serwerem proxy, obie strony konwersacji muszą wiedzieć o obecności serwera albo serwer musi umieć interpretować i modyfikować protokół, aby połączenia zwrotne były nawiązywane poprawnie i jednoznacznie. Jeśli posługujesz się zwykłym filtrowaniem pakietów, połączenia przychodzące muszą być dozwolone przez cały czas,

Strony: 1 2

Leave a reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>