On 2/11/2013 9:42 a.m., WorkingMan wrote:
> Eliezer Croitoru <eliezer <at> ngtech.co.il> writes:
>
>> On 11/01/2013 10:30 AM, WorkingMan wrote:
>>> I am not using TPROXY. VPN/SQUID are two different servers.
>> OK now you mangled everything!!
>> try to start from scratch which means design.
>> Put the VPN on the same squid server or retry to design the network in a
>> way it will work.
>> Once you will prepare the network from scratch to work in a basic way we
>> can try to dive in into squid and proxy land.
>>
>> Regards,
>> Eliezer
>>
>>
> Are you saying it's not possible to redirect traffic from a VPN
> server to a remote SQUID server box with policy based routing without
> an actual router (from the wiki it wasn't clear if that's the case or not:
> http://wiki.squid-cache.org/ConfigExamples/Intercept/IptablesPolicyRoute)?
You assume there is such as thing as "actual router". Any machine with
routing configuration enabled is a router. Even desktop machines and
smartphones can be routers if configured to do so.
> I don't like the idea of running SQUID on the VPN server because it won't
> scale. If I need to add more SQUID servers how will I route the traffic
> (so back to the original problem).
It can be done either way. However;
1) each relay/router machine the traffic goes through adds another
location where you need to setup the special routing.
2) each location may require *different* form of policy based routing or
static routing.
3) If you miss any one of the relay/routers out you will see traffic
lost/dropped and hung client connections.
> Currently I have this when policy based routing is applied (see full
> topology below):
[
There is a very specific order of packet flow required to get these
things working. And an equally specific order of configuration and
testing needed to ensure that it is all working.
I have taken the liberty of re-arranging the details you posted to
follow the order of configuration necessary to show working testing at
every step.
IFF (and only if) you have advanced networking skills can you do these
stages out of order.
Start reading the below text and comments *in-order* and ensure each
machine is showing the expected behaviour before moving on to the next one.
If any one of these stages fails to show the expected behaviour please
stop and ask for more help before continuing or experimenting further
(Im not perfect, but lets not have to re-do/undo anything complex if I
make a mistake writing this up in advane of the test results).
]
> It's very simple I want this flow to happen.
>
> client (10.100.0.0/16) <-port 500/4500-> VPN server (10.0.0.170)
> VPN server (10.0.0.170) <- port 80-> SQUID (10.0.0.117) <--> Default Gateway
> (10.0.0.1)
> VPN server (10.0.0.170) <- ! port 80-> Default Gateway (10.0.0.1)
So the Squid machine is the only one supposed to have direct contact to
Internet for this traffic. We start there, ensuring that it works
properly before setting up anything to depend on it.
** ensure the 10.0.0.1 has NAT setup to convert any 10.0.0.0/24 or
10.100.0.0/16 to public IP as is the duty of a gateway.
** ensure that 10.0.0.170 and 10.0.0.117 *both* have default gateway of
10.0.0.1
TEST ...... at this point you should:
1) be able to make any communication directly from 10.0.0.117 to any
public Internet machine.
2) be able to make any communication directly from 10.0.0.170 to any
public Internet machine.
3) tcpdump on 10.0.0.117 does NOT show any traffic from 10.0.0.170
during test (2)
> VPN Server - > Web Site (SQUID's mac),
** ensure the 10.0.0.117 machine has these configured:
> (/etc/sysctl.conf)
> net.ipv4.conf.default.rp_filter=0
> net.ipv4.conf.all.rp_filter=0
> net.ipv4.ip_forward=1
** also configure the policy based routing to ensure packets leaving
10.0.0.170 destintion port 80 are routed to 10.0.0.117.
TEST ...... at this point by generating test traffic from 10.0.0.170 you
should see in tcpdump:
1) port-80 packets 10.0.0.170 being delivered to the 10.0.0.117 machine
(visible in 10.0.0.170 tcdumps)
2) port-80 packets arriving into the 10.0.0.117 machine (visible on
10.0.0.117 tcpdumps)
3) other traffic working fine, if you want to check that it is NOT
visible on the 10.0.0.117 machine you can also do that.
IMPORTANT: if any one of the tests above fails to have the expected
result we will need to dig deeper into what is going on there between them.
> VPN Client -> VPN Server
** on the client 10.100.0.0/16 configure the default gateway to be
10.0.0.170 (or whatever the client-end of the VPN is set to).
** ensure that the routing done by 10.0.0.170 and 10.0.0.117 is able to
route 10.100.0.0/16 traffic.
NOTICE how there is no mention of NAT between 10.100.0.0/16 and
10.0.0.0/24. All the routing table entries for 10.0.0.0/24 machines need
to be able to handle packets with IP addresses in 10.100.0.0/16
NOTE: things will get quite complicated if you want other WAN
connections from the client device. Leave that complication out of the
system for now.
TEST ... at this point what you should see when generating traffic from
the client machine 10.100.0.0/16:
1) all client packets being delivered to 10.0.0.170 (visible on the
client machine)
2) all client packets are visible arriving on the 10.0.0.170 (visible on
10.0.0.170).
3) client port-80 packets being delivered to 10.0.0.117 (visible on
10.0.0.170).
4) from client viewpoint everything should be working fine.
IF and only if the above tests are all passed sucesfully are you ready
to start the Squid and interception parts of the configuration. They
take place on the Squid box and consists only of the LinuxDnat /
LinuxRedirect configuration examples in the Squid wiki.
> Can you just tell me what I need to do to make this work? It seems we
> are back to square one. It would go faster if you tell me everything in one reply
> instead of feeding each other with bits of information then
> change direction with each new information that comes along.
We have indeed gone down several different network topology
configurations and ended back at step 1.
It would have helped if we had started with the intended network diagram
below.
> It's very simple I want this flow to happen.
>
> client (10.100.0.0/16) <-port 500/4500-> VPN server (10.0.0.170)
> VPN server (10.0.0.170) <- port 80-> SQUID (10.0.0.117) <--> Default Gateway
> (10.0.0.1)
> VPN server (10.0.0.170) <- ! port 80-> Default Gateway (10.0.0.1)
>
> I am not sure if http response goes directly to original client or goes
> back from the route where it came from so It could be incorrectly drawn above.
It SHOULD be going back via the Squid box. The above is good.
Amos
Received on Sat Nov 02 2013 - 01:03:17 MDT
This archive was generated by hypermail 2.2.0 : Sat Nov 02 2013 - 12:00:05 MDT