Re: cipe-newbe

[John Carew <jon_carev,AT,yahoo,DOT,com>]

> The way to handle routing issues is to imagine
> you're a packet and
> traverse the path, looking at what's needed at each
> stop.
> 
> Starting at A, you want a packet to go to B. 
> Presumably, you mean you
> want it to go to B through the tunnel, so on A you
> make the default
> gateway be the B end of the tunnel, 10.0.0.2. 
> However for this to
> work, the tunnel must work, so packets carrying the
> tunnel (meaning
> they are addressed to B's real IP) must not try to
> go through the
> tunnel, so on A you also need a specific host route
> to B.  The gateway
> for that route is the non-tunnel default gateway of
> A.  In other
> words, if before the tunnel the default route of A
> is through some
> real IP a_gateway_ip, then on A you need two routes
>     - a host route to $real_ip with gateway
> $a_gateway_ip
>     - a default route with gateway 10.0.0.2
> 
> That gets the packet to B.  You want B to forward it
> to the internet,
> so you turn on forwarding
>     - echo 1 > /proc/sys/net/ipv4/ip_forward
> 
> B already has a default route to the internet, so
> getting it to
> forward the packet there doesn't require any routing
> change.  However,
> at this point you need to think ahead a little.  The
> packet we're
> following has A's 10.0.0.1 IP as its source address,
> so responses to
> it can't be routed, and you need to fix that.  You
> want responses to
> come back to B.  To make this happen, B must change
> the source IP to
> its own $real_ip, so on B you also have to turn on
> source NAT'ing:
>     - iptables -t nat -A POSTROUTING -s 10.0.0.1 \
>         -j SNAT --to-source $real_ip
> 
> So B sends the packet out to the internet with its
> own real IP as the
> source IP.  Remote sites see packets as being from
> B, so they send
> responses back to B.
> 
> When a response packet arrives at B, it's addressed
> to B, but B's
> connection tracking automatically recognizes it as a
> response and
> changes the destination address to 10.0.0.1 and
> forwards that to A
> through the tunnel.
> 
> You're all done, unless you want to put some icing
> on this cake.  It's
> possible, though unusual, for packets from A to
> arrive at B through
> the tunnel with A's $real_ip1 as their source
> address.  You can handle
> these also, but it's trickier.  First you need B to
> SNAT them just
> like for 10.0.0.1-source packets:
>     - iptables -t nat -A POSTROUTING -s $real_ip1 \
>         -j SNAT --to-source $real_ip
> 
> Now B will forward these too with its own source
> address.  The tricky
> part is handling the responses.  When a response
> packet arrives at B,
> it's again addressed to B, and again B's connection
> tracking
> automatically recognizes it as a response and
> changes the destination
> address.
> 
> However, this time the new destination is A's
> $real_ip1.  For the
> tunnel to work, B has to send its packets to that
> address outside the
> tunnel, but you want the responses forwarded to A
> through the tunnel. 
> 
> In other words, you want B to route packets
> differently depending on
> where they're from - packets from B itself via its
> normal gateway and
> packets from the internet via the tunnel.  This is
> policy routing.
> You need to have the iproute package installed for
> this.
> 
> The easiest way to do this is to mark packets from
> the internet on the
> way in and then do policy routing based on the
> marks.  Mark incoming
> packets in the mangle PREROUTING table, for example
> with a "1":
>     - iptables -t mangle -A PREROUTING -d $real_ip
> -j MARK --set-mark 1
> 
> Next add a rule in the RPDB (Routing Policy
> DataBase) saying to use
> some special routing table for packets marked with a
> "1".  Say you
> choose to use routing table 200:
>    - ip rule add fwmark 1 table 200 prio 1
> 
> Now you need a route in table 200:
>    - ip route add $real_ip1/32 via 10.0.0.1
> 
> (To make this all take effect, you need to flush the
> cache:
>    - ip route flush cache)
> 
> The kernel has 255 (256?) routing tables, with the
> usual routing table
> being last.  When deciding what to do with a packet
> for $real_ip1, if
> the packet is market, the kernel will find a match
> in table 200 and
> send the packet to 10.0.0.1.  If the packet is not
> marked, meaning B
> originated the packet itself, the kernel will fall
> through to the last
> routing table and send the packet outside the
> tunnel.

Well,it doesn't work. all the access to the A, is
blocked, i must reboot that machine to be online
again. Maybe i did something wrong. don't know. Has
anyone tryed this solution?
Thanks

__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com