RE: Proxy + squid
To tak:
Sieć IP VPN jest 5 krotnie droższa od SME VPN.
Sieć SME łączy oddziały firmy po przez swoją sieć strukturalną.
Bramy są określone adresami IP w sieci LAN ( niestety nie można ich
konfigurować)
Cała sieć jest o adresacji 192.168.0.0
Segment, w którym jest wyjście do WANU to 192.168.0.1-63 maska
255.255.255.192 przy czym żeby się te hosty widziały z pozostałymi w
innych segmentach to muszą mieć bramę 192.168.0.1
Pozostałe segmenty maja po 32 adresy i są skonfigurowane tak, że
pierwszy adres segmentu jest bramą.
W segmencie z WANEM wyjście jest przez adres 192.168.0.4
Potrzebuje dostarczyć Internet do segmentów bez fizycznego dojścia do
łącza WAN
Nie musze wszystkiego puszczać przez proxy zależy mi przede wszystkim na
http.
Lokalnie wszystko działa tyle, że pomiędzy oddziałami nie dział
transport netBios i wszystko idzie po IP (nie po nazwie). Działa też
domena pod warunkiem, że serwer z domena będzie miał ustawioną bramę
segmentu a wszystkie hosty odpowiednie bramy swoich segmentów.
Problem zaczyna się dopiero, kiedy np. z segmentu 2 chce się dostać do
netu. Fizyczna bramę na xp pro mam ustawioną według bram segmentu. No i
wtedy nie mogę dojść do netu, bo brama dla netu to 192.168.0.4.
Pozdrawiam
Tomek
-----Original Message-----
From: Jacek Politowski [mailto:jp@jp.pl.eu.org]
Sent: Thursday, February 22, 2007 8:59 PM
To: debian-user-polish@lists.debian.org
Subject: Re: Proxy + squid
On Thu, Feb 22, 2007 at 07:35:38PM +0100, Tomek wrote:
>Sieć jest oparta o rozwiązanie SME dostarczone przez TPS-e.
To jeszcze wytłumacz, co to jest za usługa, bo na stronach TP nic
ciekawego znaleźć nie można (czyt. w ogóle nic). Skąd więc mamy
wiedzieć co tam u siebie masz?
Z jakiegoś dziwnego forum wyczytałem tylko, że "SME VPN to polaczenie
firm bez internetu", ale co sobie TP zastrzega w umowie, a tym
bardziej co wg umowy TP zapewnia, to wielka niewiadoma.
>Jest 5
>podsieci w tej samej adresacji i tylko w jednej wyjście na zewnątrz.
Podaj konkretnie adresy sieci i maski oraz adresy routerów TP (bram) w
każdej lokalizacji, bo stwierdzenie "podsieci w tej samej adresacji"
jest mało konkretne lub po prostu dopisek "w tej samej adresacji" jest
zupełnie zbędny.
>Pomiędzy segmentami są bramy ( niestety nie mam wpływu na ich
>konfiguracje).
Trzeba było brać IP VPN, tam podobno masz ;->
ATSD, jakie są relacje cenowe między SME VPN a IP VPN? I jakie
przepustowości kanałów VPN można w SME VPN otrzymać?
>Żeby hosty z jednego segmentu widziały inne hosty
>ustawiam im bramę. W segmencie gdzie jest wyjście do wanu są dwie
bramy.
Czyli co konkretnie i gdzie ustawiasz?
Jaka usługa (podejrzewam, że również coś TP) realizuje "wyjście do
wanu"?
>Problem mam z wypuszczeniem do wanu ruchu z segmentów niemających
>fizycznego dostępu do wan.
Jeśli TP zastrzega sobie, że pomiędzy oddziałami firmy routuje tylko
pakiety pochodzące z jednego i idące do drugiego oddziału, to w sumie
nie ma się co dziwić.
Możesz oczywiście proxy w centrali postawić, ale wszystkiego nim nie
załatwisz, choć kto wie - proxy może wystarczyć.
Podejrzewam, że da się coś załatwić tunelami IPSec, PPPoE, OpenVPN lub
czymkolwiek innym - byle z punktu widzenia routerów TP pakiety latały
z adresami "lokalnymi".
Pytanie co umowa z TP określa jako ruch dozwolony (przepuszczany przez
ich routery), bo może dowolne znane im formy tunelowania nie są ruchem
akceptowalnym i nie są przepuszczane przez routery TP. Żeby to
określić, musisz odpowiedzieć na dwa pierwsze postawione przeze mnie
pytania.
Pozostaje jeszcze rozwiązanie typu 'httptunnel' ożeniony z jakimś ppp
lub 'ptunnel' - nie używałem, nie jestem pewny, ale wyglądają, jakby
mogły załatwić sprawę - pod warunkiem, że między oddziałami HTTP
przechodzi.
>Chciałem to rozwiązać za pomocą squida. Z routingiem walczyłem, ale nie
>udało mi się tego zrobić.
Część rozwiążesz (czyli mw. web), ale całego ruchu przez HTTP proxy
nie puścisz - "nie po to one są", że tak sparafrazuję współczesnego
klasyka.
I jeszcze na koniec pytanie - czemu niezależny dostęp do internetu w
każdej lokalizacji nie wchodzi w grę?
--
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: