[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

RE: Proxy + squid



Wielkie dzięki za podpowiedź i objaśnienie.
Pozwolę sobie na zabrać wam jeszcze trochę czasu jak będę miał problemy
z konfiguracją.

Przepraszam za wszystkie literówki, które wkradły się do tekstu:)

Pozdrawiam
Tomek

-----Original Message-----
From: Jacek Politowski [mailto:jp@jp.pl.eu.org] 
Sent: Friday, February 23, 2007 8:17 PM
To: debian-user-polish@lists.debian.org
Subject: Re: Proxy + squid

On Fri, Feb 23, 2007 at 03:57:11PM +0100, Tomek wrote:

>Ok.

Nie toppostuj.

>To według Ciebie jak najprościej zrobić żeby hosty z innych segmentów
>mogły korzystać z dobrodziejstw Internetu?

Jeśli faktycznie nie możesz zwrócić się do TP o zmianę konfiguracji
ich routerów w ramach SME VPN, a samo HTTP Ci wystarczy, to proxy
będzie najszybsze do skonfigurowania.

(A znasz chociaż konfigurację routerów TP? Wiesz jakie mają tablice
routingu? Albo chociaż możesz się tego dowiedzieć? Może centrala ma
jakiś defaultroute, tylko na innym adresie niż Twój gateway do
internetu? Wtedy problem masz w zasadzie z głowy.)


>A jeżeli chodzi o routing to gdzie go ustawić? Na każdym hoście z
osobna
>czy na routerze, przez który jest dostęp do netu?

Tam gdzie jest potrzebny.  Może jednak zatrudnicie jakiegoś admina?
Skoro nawet jakąś politykę macie, to może przyda się ktoś, kto ją
będzie realizował.

Skoro jedyne wyjście poza LAN we wszystkich oddziałach poza centralą
jest przez routery TP z usługi SME VPN, to w tychże oddziałach wiele
możliwości konfiguracji routingu nie masz...

A skoro nie masz też wpływu na konfigurację routerów TP, to jedyne co
możesz zrobić, to w "centrali" na każdym hoście ustawić routing
"default" do internetu i trasy przez router "SME VPN" do sieci
pozostałych oddziałów firmy.

Możesz jeszcze kombinować z ustawieniem tylko defaultroute - via
"router internetowy, a na nim ustawiać trasy do pozostałych oddziałów.
Ale jak przyjdzie Ci walczyć z ICMP redirects (także z punktu widzenia
bezpieczeństwa), to możesz mieć trudności z opanowaniem sytuacji
(niektóre urządzenia nie rozumieją redirectów, a z kolei bez
redirectów też nie zawsze musi działać - niektóre routery/firewalle
nie lubią wypuszczać pakietu tym samym interfejsem, którym go
przyjęły).

Tyle z punktu widzenia samego routingu.


>Tepsa nie widzi problemu żeby korzystać przez inne łącze netu.

Cokolwiek miałeś tu na myśli.

>Bezpośredni dostęp do Internetu jest niemożliwy ze względu na
>centralizacje i politykę zarządu (nie wszystkie segmenty mają mieć
>dostęp do netu a muszą mieć dostęp do domeny i aplikacji na serwerach
>domenowych)

Kontakt w ramach sieci korporacyjnej zapewnia Ci SME VPN, czyli dostęp
do domeny i "aplikacji na serwerach domenowych" masz generalnie
załatwiony.

Niektóre hosty? Tu grubsza sprawa, bo wszystko zależy od tego, co
deklaruje Wasza polityka i zgodnie z jej zapisami musicie dobierać
rozwiązania.

Wystarczy ruch HTTP do internetu dla wybranych użytkowników? To może
wystarczy Squid z uwierzytelnieniem (Samba, ntlm_auth?). Wszystko
zależy od tego co _dokładnie_ chcesz osiągnąć.

PPPoE, czy też inny tunel np. IPSecowy da więcej możliwości, ale i
routing skomplikuje.

A centralizacja (w sensie centralne zarządzanie i egzekwowanie polityki
dostępu np. do internetu) nie wyklucza oddzielnych styków do internetu
w wielu lokalizacjach. Nie musisz wychodzić jednym łączem w centralnej
lokalizacji. Globalne zarządzanie polityką przy wielu stykach do
internetu też jest możliwe choćby w rozwiązaniach Checkpoint, czy
FortiNet (to drugie jest z tych nieco bardziej dla śmiertelników
dostępnych ;-)


-- 
Jacek Politowski


-- 
To UNSUBSCRIBE, email to debian-user-polish-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact
listmaster@lists.debian.org




Reply to: