|
At 20:33 99-1-11 +0100, Peter Kese wrote:
>
>Hi!
>
>I have patched your kernel source code to make the VS-Router computer
>behave as a server as well. I am now able to set up a two node virtual
>server with one node configured as a server AND a router and the other
>node configured as a router only. Of course I had to configure the
>virtual server to support tunneling.
>
>I have patched the end of the demasquerade function of the ip_masq.c
>such
>that the masquerading entry selected for a given tunnel connection is
>checked whether the selected host is a local computer. If true, the
>tunneling is simply skipped and the packet left to kernel to handle it
>just as any normal packet originating from an ethernet adapter.
>
>Using ippfvsadm to add a route to the router itself, the command could
>look like this:
>
> ippfvsadm -A -t 203.1.1.10:8080 -R 127.0.0.1 (or an address of a
> local ethernet adapter)
>
>Here is what I did:
>
>--- ip_masq.c.org Thu Jan 7 13:10:39 1999
>+++ ip_masq.c Thu Jan 7 13:13:24 1999
>@@ -1893,6 +1893,7 @@
> ip_send_check(iph);
> #ifdef CONFIG_IP_MASQUERADE_IPPFVS_TUNNEL
> } else {
>+ if (ip_chk_addr(ms->saddr) == IS_MYADDR) return(0);
> if(!ip_pfvs_encapsule(skb_p, dev, ms->saddr))
> return 0;
> }
>
>As you can see, I have added only one line of code:
>
>+ if (ip_chk_addr(ms->saddr) == IS_MYADDR) return(0);
>
>The ip_chk_addr function is being checked before any packet gets
>tunneled. Insted of calling ip_chk_addr for each packet, I think it
>would be wiser to check for local addres when the masquerading-entry
>structure is generated and store it into the structure itself as a
>flag. That would speed things up, but I have decided to stay with the
>simplest patch, to keep it simple, explainable and easy to test.
Well done!
Your current implementation is simple and nice. Yeah, it is wiser to check
for local address when creating the masquerading entry and set a
LOCAL_ADDRESS flag.
>
>I have tested the kernel and it seems to work nicely. The router does
>not
>have to have a tunnel interface set up.
No, it is not necessary. Because you have already set 203.1.1.10 on an
ethernet device, it is not necessary to set 203.1.1.10 on a tunnel device.
>
>Do you think you could include such an option into the virtual server
>kernel patch (maybe in next release)?
Sure, I will include your patch into next release. However, I will set up a
compiling option for it. If people want it, they can enable it. If not,
they just skip it, they won't lose time on local address checking.
>
>Cheers,
>
> Peter
>
>
>P.S. Any chance of porting the patch to 2.0.36/37. How about the 2.2.xx
>kernels... will there be a VS patch too?
>
Any porting to 2.0.36/37, 2.1.*** or 2.2.xx is welcome. I will include it
in the next release.
Best regards,
Wensong
|
