SOCKS proxy server dostępny jest z adresu:
ftp://sunsite.unc.edu/pub/Linux/system/Network/misc/socks-linux-src.tgz.
Zawiera przykładowy plik konfiguracyjny w katalogu nazwanym:
" socks-conf " . Zdekompresuj i untaruj te pliki
w dowolnym katalogu i postępuj według instrukcji.
Miałem kilka problemów kiedy kompilowałem go. Upewnij się, że twój
Makefile jest prawidłowy.
Jedną z ważniejszych rzeczy jest pamiętanie o konieczności dodania
serwera proxy do /etc/inetd.conf.
Aby móc odpowiedzieć na żądania musisz dopisać następującą linię:
socks stream tcp nowait nobody /usr/local/etc/sockd sockd
Program SOCKS potrzebuje dwóch oddzielnych plików konfiguracyjnych. Jeden z nich mówi tym komu udzielić dostępu a drugi w jaki sposób przekazywać żądania do właściwego serwera proxy. Plik decydujący o dostępie powinien znajdować się na serwerze. Plik dotyczący przekazywania dostępu (routingu) powinien znajdować się na każdej z maszyn Unixowych. W wypadku DOSa i częściowo MaCów komputery powinny mieć swój własny routing.
W wersji 4.2 Beta SOCSKsów plik dostępu nazywa się " sockd.conf " . powinien zawierać dwie linie: zezwolenia i zakazu. Każda z linii posiada trzy pozycje:
permit lub deny
Powinieneś użyć obu: każdy we właściwej linii.
Adres IP powinien zawierać czterobajtowy adres w typowej dal IP
notacji.
np. 192.168.2.0.
Modyfikator adresu także jest normalnym IP i pracuje jak maska.
Rozwinięcie tego adresu da 32 bity (1 albo zero).
Na przykład, w tej linii:
permit 192.168.2.23 255.255.255.255zezwalam na dostęp maszynom w których adres pasuje co do bitu z zadanym: pasuje tu tylko 192.168.2.23
permit 192.168.2.0 255.255.255.0zezwala na dostęp maszynom z gdyby od 192.168.2.0 do 192.168.2.255, w formie całej klasy C.
Nie powinieneś mieć następującej linii:
permit 192.168.2.0 0.0.0.0dającej dostęp dla wszystkich adresów.
Tak więc pierwsza linia daje zezwolenie dla tych adresów którym chcesz go dać, a druga zakazuje reszcie. Aby zezwolić na dostęp wszystkim z klasy 192.168.2.xxx potrzeba linii:
permit 192.168.2.0 255.255.255.0 deny 0.0.0.0 0.0.0.0Zwróć uwagę na pierwsze " 0.0.0.0 " w linii zakazu. Z maską 0.0.0.0 taki adres nie istnieje. Wszystkie zera zostały tam wprowadzone bo są łatwe do zapisu.
Dopuszczalne jest umieszczenie większej ilości jeden zapisów w
każdej
z linii.
Konkretni użytkownicy mogą ponadto otrzymać lub tracić prawo
dostępu.
jest to wykonywane przy pomocy autentyfikacji przy pomocy
ident. Nie wszystkie systemu używają ident,
włączając w to
Trumpet Winsock , dlatego też nie włączam tu przykładów.
Dokumentacja do SOCKS jest całkiem dobra w tej kwestii.
Tablica routingu w SOCS jest niestety nazywana
socks.conf.
Tablica routingu mówi klientom SOCKS kiedy używać socks a kiedy nie. Na przykład, w twojej sieci 192.168.2.3 nie potrzebuje używania socks do połączenia z 192.168.2.1. Po prostu łączy się bezpośrednio, po Ethernecie. Definiuje się automatycznie 127.0.0.1 jako loopback. Oczywiste jest, że nie potrzebujesz rozmawiać przez ścianę ogniową z samym sobą...
Są trzy typy rekordów:
Deny mówi SOCKS kiedy ma odmówić żądaniu. Rekord ten ma
takie
same trzy pola jak sockd.conf: identyfikator, adres i
maska.
Ogólnie, dopóki jest to modyfikowane przez sockd.conf,
maska w pliku dostępu jest ustawiona na 0.0.0.0. Jeśli chcesz
pozwolić
na dzwonienie do siebie możesz to zrobić tutaj.
Rekord direct mówi które do których adresów nie używać
SOCKS.
Te adresy będą doręczone bez serwera proxy.
Jeszcze raz, mamy trzy pola: identyfikator, adres i maska.
direct 192.168.2.0 255.255.255.0W ten sposób kierujesz bezpośrednio cały ruch w chronionej sieci.
Rekord z sockd
mówi komputerowi które z hostów są serwerem SOCKS
Składnia jest następująca:
sockd @=<serverlist> <IP address> <modifier>Zwróć uwagę na fragment: @= . Pozwala on na wprowadzenie listy serwerów proxy. W naszym przykładzie używamy tylko jednego. Ale możesz mieć wiele w celu zwiększenia przepustowości i obniżenia możliwości awarii.
Pola adresu IP i maski działają jak w innych przykładach. Specyfikujesz adres i zakres jego obowiązywania.
Aby twoje aplikacje działały z serwerami proxy
potrzebujesz je zsockisy... ( " sockified " ).
Będziesz potrzebował dwóch różnych telnetów (jeden do komunikacji
bezpośredniej drugi przez serwer proxy). SOCKS przychodzą z
instrukcją jak zSOCKifikować program, i z paroma programami
przygotowanymi na tę modłę. Jeśli używasz zSOCKIfowanej wersji
gdziekolwiek bezpośrednio SOCKS automatycznie przełączy cię na
właściwą
wersję. Z tego powodu trzeba zmienić nazwy wszystkich programów w
naszej
chronionej sieci i zstąpić je wersjami
zSOCKisowanymi. Finger stanie
się finger.orig, telnet stanie się
telnet.orig i
tak dalej.
Musisz powiedzieć SOCKS o każdym w pliku include/socks.h.
Dobre programy są w stanie dostarczać tablic trasowania i zsocksifikować się same. Jednym z nich jest Netscape Navigator. Możesz używać serwerów proxy przez wprowadzenie adresu serwera (192.168.2.1 w naszym wypadku) w polu SOCKs w Menu Proxies. Każda aplikacja potrzebuje przynajmniej minimalnej informacji o tym co jest serwerem proxy.
Trumpet Winsock przychodzi z wbudowanymi możliwościami współpracy z
serwerem proxy. W
setup menu wprowadź adres serwera, i adresy
komputerów dostępnych bezpośrednio. Program przekieruje na serwer
wszystkie pakiety mające wyjść na zewnątrz.
Pakiet SOCKS pracuje jedynie z pakietami TCP, pomijając UDP.
Powoduje to trochę mniejszą jego użyteczność. Wiele użytecznych
programów, takich jak na przykład talk i Archie
używa UDP. Jest jednak pakiet
który może być użyty jako serwer proxy dla UDP: UDPrelay
stworzony
przez Toma Fitzgeralda
fitz@wang.com. Niestety w chwili
pisania tego tekstu nie jest on zgodny z Linuxem.
Serwer proxy, jak pokazałem powyżej jest
narzędziem bezpieczeństwa.
Używanie go zwiększa dostępność do Internetu z ograniczoną liczbą
adresów
wiąże się jednak z wieloma niedogodnościami. Serwer proxy
pozwala
na większą dostępność internetu z sieci chronionej, ale pozostawia
wnętrze
całkowicie niedostępne z zewnątrz. Oznacza to brak możliwości
uruchomienia
wewnątrz sieci rozmaitych serwerów, talk i archie, oraz
bezpośredniego wysyłania listów do chronionej sieci.
Poniższe uchybienia wyglądają nieznacząca, ale sposób myślenia
przebiega następująco:
Przypadek FTP pokazuje jeszcze jeden problem z serwerami
proxymi. Kiedy pobieram pliki lub wydaję komendę ls,
serwer FTP otwiera gniazdo (,,socket'') na maszynie klienckiej
i wysyła o tym informację. Serwer proxy nie pozwala na to, tak
więc FTP nie działa w sposób prawidłowy.
Poza tym serwery pośredniczące działają powoli. Z powodu większej wydajności większość innych metod dostępu do Internetu będzie szybsza.
Jeśli masz przydzielony adres IP, i nie martwisz się o bezpieczeństwo,
nie używaj ścian ogniowych i/lub serwerów proxych.
Jeśli nie masz nr. IP, i także nie martwisz się o bezpieczeństwo
swojej sieci, możesz użyć jednego z ,,emulatorów IP'' takich jak
Term, Slirp lub TIA. Term jest dostępny z
ftp://sunsite.unc.edu/, Slirp z
ftp://blitzen.canberra.edu.au/pub/slirp, zaś TIA z
http://markertplace.com/.
Pakiety te pracują szybciej, pozwalają na szybsze połączenia i na
większy dostęp z sieci wewnętrznej do internetu.
Serwery pośredniczące są dobre dla tych który mają duże sieci
z komputerami mającymi mieć dostęp ,,w locie'' do internetu
z jednorazowym ustawieniem, i minimalnym wkładem pracy potem.