On 7/14/2012 3:21 PM, Wayne Lee wrote:
HI Eliezer
Thanks for your reply.
SNIP>
if you could be more accurate about the cables setup and logic and not just
ip it can help understand things.
squid-----Switch----Cisco router
|
|
|
gateway
Cat 5 ethernet
to sort it..
if i do understand correctly the cisco router is the squid gateway..
and the gateway is another machine.
so the sessions flow is
forward:
client-->LNS-->switch-->squid-->--switch->LNS-->switch->GW-->the server
back:
server-->GW-->switch-->LNS-->switch-->squid-->switch-->LNS-->client
this is inefficient since you have one switch usage that can be changed.
and it explains your problem.
the problem is that the traffic that comes from the internet suppose to get
into the proxy machine but it's going to the client which is not listening
to the same socket.
wccp + tproxy dont play good together!!!
if you will run tcpdump on the client machine you will see packets of
sessions that started on the squid box arriving to it.
you dont need to be with this 3 days.
just buy a 1Gbit Ethernet card and put a small bridge between the cisco and
the next hop.
I can add interfaces without problem as the squid box is a VM
When running tcpdump on the client machine I do not see any return
packets when using tproxy or DNAT methods.
When using the DNAT method and running tcpdump on the squid box I can
see the inbound request from the client and the return packets from
the webserver but nothing gets returned to the client
When using the tproxy method and running tcpdump on the squid box I
can see the inbound request from the client but that request is not
passed to squid and does not leave the squid box so no return packets
are seen on squid or the client.
before implementing and testing anything you should first ask yourself
what are your needs.
if it's an ISP or OFFICE environment that you do care about what client
IP visibility to the world for any reason to be.
And to take in account that IPV6 days are coming and the only way to
intercept it will be TPROXY you should go with TPROXY.
if you dont care for any reason there is about what IP the servers after
this "Junction" will see then the Intercept way is good until IPV6 comes
around.
you dont need to use DNAT you can use REDIRECT and it will be good.
i have tested it in my lab today just to make sure.
it depends.
you can always do something with vlans and stuff to make one interface act
like two.
with tproxy the traffic that comes from the proxy is the same as the one
that comes from the client.
10.10.254.254 comes in and 10.10.254.254 comes out.
so the only options you have are:
use some routing technique such as routing map with next hop.
you can setup the cisco to send traffic to the squidbox using one ip that
squid will use as gw for the clients network.
and second ip to access the net and from the net.
this way squid will be a "router" on the way.
another option is the bridge thing with two networks cards.
you can play with vlans and bridge two vlans but it's pretty nasty to do so.
Regards,
Eliezer
Which method is the best way to go, DNAT or tproxy and what else can I
do to debug the process?
The final goal once testing is complete is to have 5 LNS's using the
proxy, the proxy will be on a different subnet to the LNS's.
Thanks
Wayne
It's better to implement the TPROXY but beware as you know you must
understand what is going on all the time.
first understand what TPROXY and INTERCEPT are:
when cache proxy intercepts a request the client only talks to the proxy
and thinks he is talking to the origin server while squid is talking
with the origin server with his own IP.
so routing rules are plain.. for the gw:
when you get ip from client send to squid.
when you get ip to the client send to client.
when you get ip from squid send to world.
when you get ip to squid send to squid.
simple routing.
wccp makes the routing interception more fault tolerance and scalable
over couple proxies.
TPROXY packets can be identified only at level 2 with WCCP which seems
to not work for me on one interface.
i have also seen that using cisco WAE and Policy-Based Routing.
what i would suggest is:
puts some routing rules based on acls\routing policies on each of the
routers.
since the LNS routes can be changed always it's better to use the other
gateway as the "interceptor".
client ->LNS1\2\3\4\5->GW->squid port 1\vlan 1 -> GW port 2\vlan 2 -
internet.
internet-->GW-->SQUID port 2\vlan 2 -->GW port 1\vlan 1 -->LNS
1\2\3\4\5-client.
this flow will give you better survivability and centralization.
i suppose the GW will use some kind of routing protocol to get clients
IP routes.
you will need to use 2 pairs of /30 subnet for this setup.
on the GW machine you will need to do some routing based on dst and src
ports of 80\8000\8080 etc.. to distinct www and other traffic.
you dont need traffic other then www to be routed to the squid box.
if you have list of the clients subnets you can put together on the
tproxy machine two different static routing path.
one as the default GW(vlan2) with high metric and lower metrics a static
routes to the clients subnets (to vlan1).
if you want to work specifically with cisco you can use the CDP protocol
as a replacement to WCCP "web-cache" status.
there is a nice tool for linux:
http://code.google.com/p/ladvd/
takes about a minute to compile and will give you an option to use
"route-map" based on "set ip next-hop verify-availability".
well all this is based on the basic understanding of cisco 2800 series
capabilities.
in you scenario i think it's better to use squid as a ROUTER with tproxy
and not as a BRIDGE.
Regards,
Eliezer
--
Eliezer Croitoru
https://www1.ngtech.co.il
IT consulting for Nonprofit organizations
eliezer <at> ngtech.co.il
