Serwer proxy Squid

W tym rozdziale opiszemy, jak działa buforowanie stron internetowych za pomocą serwera proxy Squid, a także jak zablokować dostęp do niektórych stron internetowych dla użytkowników z sieci lokalnej.

W tym rozdziale opiszemy, jak działa buforowanie stron internetowych za pomocą serwera proxy Squid, a także jak zablokować dostęp do niektórych stron internetowych dla użytkowników z sieci lokalnej.

Squid to jeden z najbardziej popularnych serwerów proxy do platform uniksowych i/lub linuksowych. Oprogramowanie działa jak pośrednik w transakcjach. Zbiera zapytania od klientów, w tym przypadku od przeglądarek internetowych, i przekazuje je do odpowiednich serwerów w Sieci. Zamówione dane trafiają do serwera proxy, który przekazuje je klientom w sieci lokalnej.

Serwer proxy tworzy przy tym kopię strony w lokalnym buforze na swoim twardym dysku. Korzyści z tego stają się widoczne, gdy wiele klientów żąda tych samych stron internetowych. Serwer wysyła je wówczas ze swojego lokalnego bufora, a więc znacznie szybciej niż wtedy, gdy musi pobierać je z Internetu.

Oprogramowanie serwera proxy Squid oferuje bardzo szeroki zakres funkcji. Umożliwia m.in określenie hierarchii do rozdziału obciążenia systemowego w przypadku stosowania wielu serwerów proxy, a także ustanowienie wielu reguł dostępu dla klientów, które chcą odwoływać się do serwera proxy, przyznawanie i cofanie praw dostępu do określonych stron internetowych za pomocą innych aplikacji oraz sporządzanie statystyk najczęściej odwiedzanych stron internetowych.

Squid jako typowy serwer proxy - zasadniczo pośredniczy jedynie w połączeniach HTTP. Obsługuje też protokoły FTP, Gopher, SSL i WAIS. Nie obsługuje natomiast niestandardowych protokołów internetowych, np. strumieni RealAudio.

Squid odwołuje się do protokołu UDP wyłącznie w celu obsługi komunikacji między różnymi buforami. Podstawowe oraz szczegółowe informacje na temat protokołu UDP i pakietu protokołów TCP/IP znajdziesz w następnych rozdziałach.

Buforowanie w sieci lokalnej

Szczegółowe informacje. Serwer zapisuje w pliku cache.log wszystkie szczegóły swojej aktywności. To bardzo pomaga wyszukiwać błędy.

Szczegółowe informacje. Serwer zapisuje w pliku cache.log wszystkie szczegóły swojej aktywności. To bardzo pomaga wyszukiwać błędy.

Nawet jeżeli nie jest to konieczne z punktu widzenia zastosowań SuSE Linux Office Server i ze względu na wielkość sieci, omówimy krótko możliwość zastosowania w sieci lokalnej wielu buforów z wykorzystaniem serwera Squid. Wszystkie przykłady konfiguracji opierają się jednak na założeniu, że serwer proxy pracujący na Office Server jest jedyny w tej sieci lokalnej.

W sieci lokalnej można skonfigurować kilka buforów tak, żeby wymieniały między sobą pakiety. Zmniejsza to obciążenie systemu, zwiększając jednocześnie prawdopodobieństwo, że poszukiwany obiekt znajduje się już w jednym z buforów. Można też zastosować kompletną hierarchię buforów. Bufor X będzie kierować zapytania do innych buforów, równorzędnych w hierarchii lub zlecać buforowi nadrzędnemu poszukiwanie obiektu w innych buforach w sieci lokalnej albo pobranie go bezpośrednio z Internetu.

Całą tą komunikacją steruje oparty na UDP tzw. Internet Cache Protocol, w skrócie ICP. Wymiana danych między buforami odbywa się przez HTTP na bazie TCP. Aby wyszukać najlepszy serwer do danego zapytania o obiekt, bufor wysyła zapytanie ICP do wszystkich serwerów proxy na tym samym poziomie hierarchii. Serwery proxy reagują wówczas odpowiedzią ICP o treści "HIT", jeżeli dysponują poszukiwanym obiektem, lub o treści "MISS", jeżeli jest inaczej. W razie otrzymania wielu odpowiedzi "HIT" proxy wybiera jeden z serwerów i pobiera dane.

O wyborze serwera decyduje m.in. czas nadesłania odpowiedzi.

Jak Squid przechowuje obiekty internetowe?

Wszechstronny talent. Polecenie rcsquid to wygodna możliwość kontrolowania pracy serwera.

Wszechstronny talent. Polecenie rcsquid to wygodna możliwość kontrolowania pracy serwera.

Nie wszystkie obiekty dostępne w Internecie są statyczne. Jest wiele stron generowanych dynamicznie, z licznikami dostępu, lub stron szyfrowanych SSL. Tych obiektów nie można przechowywać na serwerze proxy. Podczas każdej próby dostępu okazuje się, że obiekt się zmienił.

W wypadku wszystkich innych obiektów, np. statycznych stron internetowych, rodzi się pytanie, jak długo powinny być przechowywane. Aby na nie odpowiedzieć, wszystkie obiekty przechowywane w buforze dzieli się na trzy klasy:

  • Nowe - gdy przychodzi żądanie takiego obiektu, proxy wysyła go natychmiast do klienta, bez wcześniejszego porównania z oryginałem w Internecie.

  • Normalne - zanim Squid dostarczy obiekt z bufora, sprawdza najpierw, czy oryginał w Internecie zmienił się. Jeżeli tak, obiekt jest aktualizowany przed wysłaniem.

  • Przestarzałe - obiekt zostaje uznany za przestarzały i pobierany jest nowy obiekt z Internetu.

    Mnogość opcji. Zakres konfiguracji Access Control Lists jest bardzo obszerny.

    Mnogość opcji. Zakres konfiguracji Access Control Lists jest bardzo obszerny.

    Serwer proxy Squid uzyskuje odpowiednie dane o statusie obiektów z ich nagłówków o treści składającej się z komentarza w rodzaju "Last modified" lub "Expires" i daty. Stosowane są również inne nagłówki, które na przykład wskazują, że dany obiekt nie powinien być przechowywany.

    Ponieważ pojemność bufora jest ograniczona, obiekty muszą być regularnie zastępowane nowymi. Serwer podejmuje decyzje na podstawie specjalnych algorytmów, np. Last Recently Used (LRU). W gruncie rzeczy całość polega na zastępowaniu obiektów najrzadziej wywoływanych innymi, bardziej popularnymi.

    Wymagania systemowe serwera proxy

    Im mniejszy bufor, tym mniejsze prawdopodobieństwo pojawienia się komunikatu o treści "HIT", czyli informacji, że żądany obiekt znajduje się w buforze. Tak więc obiekt często musi być pobrany z Internetu. Aby ustalić właściwą wielkość bufora, trzeba wykonać kilka obliczeń. Jeżeli serwer Squid ma do dyspozycji na przykład 1 GB przestrzeni dyskowej, podczas gdy użytkownicy w sieci lokalnej potrzebują dziennie 10 MB stron internetowych, dysk serwera proxy zapełni się dopiero po 100 dniach.

    Wielkość bufora najłatwiej obliczyć na podstawie przepustowości łącza internetowego. Łącze 1 Mb/s oznacza w praktyce realny transfer około 125 Kb/s. Gdyby cały ruch był buforowany, wówczas w ciągu godziny należałoby zapisać 450 MB danych, zatem przeciętny, ośmiogodzinny dzień roboczy to 3,6 GB danych. Ponieważ jednak dane nie płyną nieprzerwanym strumieniem przez cały dzień, z reguły wystarczy bufor wielkości 1,5 do 2 GB, żeby zapisać strony internetowe pobrane w ciągu jednego dnia roboczego.

    Rozmiar pamięci RAM serwera Squid zależy od wielkości bufora dyskowego, bo serwer proxy dodatkowo przechowuje często pobierane strony w pamięci RAM, aby móc je jeszcze szybciej dostarczać. W pamięci RAM przechowywane są również inne informacje, m.in. tabele ze wszystkimi przyznanymi adresami IP oraz różne listy kontroli dostępu. Obowiązuje stara zasada - im więcej pamięci, tym lepiej.

    Squid a SuSE Linux Office Server

    Krynica wiedzy. Na stronie www.squidguard.org znajdziesz wiele informacji na temat konfiguracji programu.

    Krynica wiedzy. Na stronie www.squidguard.org znajdziesz wiele informacji na temat konfiguracji programu.

    Po instalacji SUSE Linux Office Server serwer proxy Squid jest już skonfigurowany w ogólnych zarysach i uruchamiany wraz ze startem systemu. Udostępnia też od razu pewne funkcje podstawowe, bez żadnej ingerencji:

  • Buforowanie stron internetowych - wszystkie klienty w sieci lokalnej mogą przechowywać pobrane strony internetowe.

  • Ograniczenie dostępu - serwer proxy Squid jest tak skonfigurowany, że z jego usług mogą korzystać tylko klienty w sieci lokalnej.

  • Zarządzanie buforowaniem - program Cache Manager pozwala na sporządzanie w dowolnym czasie statystyk, na podstawie których można określić rzeczywiste zapotrzebowanie na usługi serwera proxy.

    W dalszym ciągu opiszemy, jak optymalnie dostosować serwer proxy do swoich potrzeb. W szczególności zajmiemy się tworzeniem reguł dostępu do Internetu i blokowaniem dostępu do określonych stron internetowych z sieci lokalnej.

    Uruchamianie serwera proxy, ponowne uruchamianie, kończenie pracy i kontrola statusu

    Jako użytkownik root możesz wygodnie sterować ręcznie serwerem proxy Squid za pomocą polecenia rcsquid. Polecenie rcsquid start uruchamia serwer i po pomyślnym zakończeniu zwraca komunikat statusu "Starting WWW-proxy squid done". Jeżeli wprowadzisz jakiekolwiek zmiany w głównym pliku konfiguracyjnym /etc/squid.conf, będziesz musiał za każdym razem zrestartować serwer.

    Masz do dyspozycji dwie możliwości: rcsquid reload powoduje, że serwer wczytuje tylko zmiany w tym pliku; alternatywne polecenie rcsquid restart wymusza pełny restart serwera. Polecenie rcsquid status wyświetla aktualny status serwera, czyli informuje o tym, czy jest uruchomiony, czy też nie. Polecenie rcsquid stop kończy pracę serwera. O tym, czy serwer proxy ma być automatycznie uruchamiany przy starcie systemu, decyduje opcja START_SQUID w pliku /etc/rc.config.

    Zamykanie serwera trwa dość długo, ponieważ Squid czeka pół minuty na zakończenie połączeń z klientami, a następnie zapisuje dane na dysku. Czas zamykania zależy od parametru shutdown_lifetime w pliku /etc/squid.conf.

    Gwałtowne zakończenie pracy serwera proxy poleceniem kill względnie killall może zrujnować pamięć buforową. Trzeba wówczas usunąć jej zawartość przed ponownym uruchomieniem serwera Squid.

    Jeżeli serwer proxy samoczynnie kończy pracę krótko po tym na pozór pomyślnym starcie, przyczyna może tkwić w błędnym wpisie serwera nazw lub w braku pliku /etc/resolv.conf. Powód niespodziewanego zakończenia pracy serwer zapisuje w pliku /var/squid/logs/cache.log.


  • Zobacz również