|
||||||||
|
|
#1
|
|
Hi all,
Generally speaking, in an IP network, any IP packet which reach a node (workstation, gateway, router...), and whichever the incoming interface, will either be caught and absorbed by this node if it is the intended recipient, or redirected for output (IP forwarding) through [another] interface in respect to the current routing policy. But I have a weird goal to achieve: On a linux box 'A' which has interfaces eth0, eth1, eth2, eth3, I would like to do a special treatment on packets incoming via eth0 and whose source is <some-network>. I would like these packets be unconditionaly redirected unmodified for output via interface eth1. That is: - even if they were targeted (destination IP) at my box 'A', they will be re-emitted through eth1. - even if they would have been forwarded through eth2 or eth3, they will be re-emitted through eth1 too. Any idea to help me reach this goal? Sincerely, Le Testeur none |
|
#2
|
|||
|
|||
|
none wrote:
> Hi all, > > > Generally speaking, in an IP network, any IP packet which reach a node > (workstation, gateway, router...), and whichever the incoming interface, > will either be caught and absorbed by this node if it is the intended > recipient, or redirected for output (IP forwarding) through [another] > interface in respect to the current routing policy. > > But I have a weird goal to achieve: > > On a linux box 'A' which has interfaces eth0, eth1, eth2, eth3, I would > like to do a special treatment on packets incoming via eth0 and whose > source is <some-network>. > > I would like these packets be unconditionaly redirected unmodified for > output via interface eth1. > > That is: > - even if they were targeted (destination IP) at my box 'A', they will > be re-emitted through eth1. > - even if they would have been forwarded through eth2 or eth3, they > will be re-emitted through eth1 too. > > > Any idea to help me reach this goal? > > > Sincerely, > Le Testeur You need to read "raw" packets at eth0 and write them to eth1. "man packet" will get you started. There is also a library "libpcap" that is used by tcpdump which you may find useful. Robert |
|
#3
|
|||
|
|||
|
Robert Harris <(E-Mail Removed)> writes:
>none wrote: >> Hi all, >> >> >> Generally speaking, in an IP network, any IP packet which reach a node >> (workstation, gateway, router...), and whichever the incoming interface, >> will either be caught and absorbed by this node if it is the intended >> recipient, or redirected for output (IP forwarding) through [another] >> interface in respect to the current routing policy. >> >> But I have a weird goal to achieve: >> >> On a linux box 'A' which has interfaces eth0, eth1, eth2, eth3, I would >> like to do a special treatment on packets incoming via eth0 and whose >> source is <some-network>. >> >> I would like these packets be unconditionaly redirected unmodified for >> output via interface eth1. That is silly, since then they would still have exactly the same packet headers and address that they had coming in-- ie your box A address on the wrong network. It, all that can happen is that they get thrown away since the address cannot be found. You seem to be confused as to what an ip packet is ( or maybe I am). It has a header, saying where it is going and where it came from. It has contents. YOu are asking like-- I want all letters coming to my house to be thrown back into the post box immediately in the same envelope they came in. In the best circumstance they will get delived right back to you again. In the worst they will get thrown away. In no case does this accomplish anything useful Perhaps you should tell us what you want to accomplish and we might be able to tell you how to do not. >> >> That is: >> - even if they were targeted (destination IP) at my box 'A', they will >> be re-emitted through eth1. And what is supposed to happen to them then? >> - even if they would have been forwarded through eth2 or eth3, they >> will be re-emitted through eth1 too. No idea what this means. >> >> >> Any idea to help me reach this goal? >> >> >> Sincerely, >> Le Testeur >You need to read "raw" packets at eth0 and write them to eth1. >"man packet" will get you started. There is also a library "libpcap" >that is used by tcpdump which you may find useful. >Robert |
|
#4
|
|||
|
|||
|
Hi -
On Thu, 27 Sep 2007 19:36:35 +0200, none <""testr\"@(none)"> wrote: >On a linux box 'A' which has interfaces eth0, eth1, eth2, eth3, I would >like to do a special treatment on packets incoming via eth0 and whose >source is <some-network>. > >I would like these packets be unconditionaly redirected unmodified for >output via interface eth1. > >That is: > - even if they were targeted (destination IP) at my box 'A', they will >be re-emitted through eth1. > - even if they would have been forwarded through eth2 or eth3, they >will be re-emitted through eth1 too. If they would be forwarded anyway, advanced routing can be used to force them out a specific interface. For packets whose destination is 'A', I think you would need to do something with netfilter to get the packets on to the forwarding chain, but I don't know how without changing the destination IP address. -- Ken http://www.kensims.net/ |
|
#5
|
|||
|
|||
|
On 09/28/2007 09:44 AM, Ken Sims wrote:
> Hi - > > On Thu, 27 Sep 2007 19:36:35 +0200, none <""testr\"@(none)"> wrote: > >> On a linux box 'A' which has interfaces eth0, eth1, eth2, eth3, I would >> like to do a special treatment on packets incoming via eth0 and whose >> source is <some-network>. >> >> I would like these packets be unconditionaly redirected unmodified for >> output via interface eth1. >> >> That is: >> - even if they were targeted (destination IP) at my box 'A', they will >> be re-emitted through eth1. >> - even if they would have been forwarded through eth2 or eth3, they >> will be re-emitted through eth1 too. > > If they would be forwarded anyway, advanced routing can be used to > force them out a specific interface. > > For packets whose destination is 'A', I think you would need to do > something with netfilter to get the packets on to the forwarding > chain, but I don't know how without changing the destination IP > address. If forwarding is enable, which indeed should be, on this machine acting/imitating as router, I on Redhat like machines shall create an alias eth1:0, whereas on Debian and, or Ubuntu I shall use iproute/iprute2 as follows: # ip addr add dev eth1 local net.wo.rkX.host/ne.tm.as.kX I OTOH, am curious to know, how netfilter/iptables can forward packets? Do we have kind of some FORWARD target for PREROUTING chain? -- Dr Balwinder S "bsd" Dheeman Registered Linux User: #229709 Anu'z Linux@HOME Machines: #168573, 170593, 259192 Chandigarh, UT, 160062, India Gentoo, Fedora, Debian/FreeBSD/XP Home: http://cto.homelinux.net/~bsd/ Visit: http://counter.li.org/ |
|
#6
|
|||
|
|||
|
none wrote:
> Hi all, > > > Generally speaking, in an IP network, any IP packet which reach a node > (workstation, gateway, router...), and whichever the incoming interface, > will either be caught and absorbed by this node if it is the intended > recipient, or redirected for output (IP forwarding) through [another] > interface in respect to the current routing policy. > > But I have a weird goal to achieve: > > On a linux box 'A' which has interfaces eth0, eth1, eth2, eth3, I would > like to do a special treatment on packets incoming via eth0 and whose > source is <some-network>. > > I would like these packets be unconditionaly redirected unmodified for > output via interface eth1. > > That is: > - even if they were targeted (destination IP) at my box 'A', they will > be re-emitted through eth1. > - even if they would have been forwarded through eth2 or eth3, they > will be re-emitted through eth1 too. > > > Any idea to help me reach this goal? > > > Sincerely, > Le Testeur Hello all, I especially thank the four people (until now) who afforded taking time to answer me. I must say you: even if my goal has puzzled you a bit, your answers helped me a bit to grasp what the directions I shall investigate are. Now, it's my turn to expose why I explained my original goal that way: I have a box 'A' with interface (ethernet) eth0 and I wanted to do ingress SHAPING on eth0 : each stream family/network would be allocated a dedicated bandwidth. But up to now, Linux has very poor support for ingress SHAPING : it only allows a 'blind' ingress BANDWIDTH LIMITING. I heard of the IMQ (InterMediate Queueing device) to get rid of this ingress technical limitation. But I run a too heavily patched and a too hard to build Linux kernel to afford entering the process to patch the kernel and the toolset for IMQ compliance. So it happened to me that I could make my box 'A' to reflect (like a mirror) some of the packets incoming on interface eth0 (physical ethernet) to some Virtual TAP tap2 * and get them back (whichever the means) on Virtual TAP tap3 * to do Real & Effective egress SHAPING on Virtual TAP tap2, thus to do Effective ingress SHAPING on eth0 which is my initial goal. * The both interfaces being provided by the Linux Universal TUN/TAP driver. Then I straightly considered using a UML (User Mode Linux) virtual machine, which has a full network stack, to join the two Virtual TAPs tap2 & tap3 and make them communicate to create the missing 'tunnel'. In this scenario, it would not have been to complicated to provide my box 'A' with functional networking & a good 'ingress SHAPING'. The point where the whole story became funny and a bit weird was when I decided not to waste system resources to a whole virtual machine (like UML). Then I bet I could reach the same initial goal with different technical means. I decided to join my two Virtual TAP interfaces by a bare tunnel. I failed to use Vtun for this purpose, but I managed to use OpenVPN which I was already used to. For this purpose, I thought to allocate my two Virtual TAP interfaces' IP addresses on the same [virtual] ethernet segment, which I don't know if it is really usefull. But now, I'm stuck at two key points: - 1) Grasp the mechanisms involved in this overall networking scheme, with all the meaningful details. - 2) Do the proper routing/forwarding/masquerading on my box, the box 'A'. Please, say me if I am an awkward/clumsy/stubborn system/network admin. I would much appreciate if you could make me suggestions on how to achieve my goal. I'm hearing for you all. Thanks, Le Testeur |
|
#7
|
|||
|
|||
|
Unruh wrote:
> Robert Harris <(E-Mail Removed)> writes: > >> none wrote: >>> Hi all, >>> >>> >>> Generally speaking, in an IP network, any IP packet which reach a node >>> (workstation, gateway, router...), and whichever the incoming interface, >>> will either be caught and absorbed by this node if it is the intended >>> recipient, or redirected for output (IP forwarding) through [another] >>> interface in respect to the current routing policy. >>> >>> But I have a weird goal to achieve: >>> >>> On a linux box 'A' which has interfaces eth0, eth1, eth2, eth3, I would >>> like to do a special treatment on packets incoming via eth0 and whose >>> source is <some-network>. >>> >>> I would like these packets be unconditionaly redirected unmodified for >>> output via interface eth1. > > That is silly, since then they would still have exactly the same packet > headers and address that they had coming in-- ie your box A address on the > wrong network. It, all that can happen is that they get thrown away since > the address cannot be found. I didn't want to appear so silly; the tricky point here is to setup the right route on some other node B, on which ethernet segment node A's eth1 delivers packets, so that node B re-route packets to their expected recipient in respect to the following two rules: - 1) If the recipient is node A, the route WILL NOT involve node A's eth0 but some other interface of node A. - 2) Node B will not fear IP spoofing (packets coming back and forth may appear suspicious). > > You seem to be confused as to what an ip packet is ( or maybe I am). It has > a header, saying where it is going and where it came from. It has contents. > YOu are asking like-- I want all letters coming to my house to be thrown > back into the post box immediately in the same envelope they came in. In > the best circumstance they will get delived right back to you again. In the > worst they will get thrown away. In no case does this accomplish anything > useful Perhaps you should tell us what you want to accomplish and we might > be able to tell you how to do not. >>> That is: >>> - even if they were targeted (destination IP) at my box 'A', they will >>> be re-emitted through eth1. > > And what is supposed to happen to them then? They are supposed to join node A again incoming via any interface other than node A's eth0. > >>> - even if they would have been forwarded through eth2 or eth3, they >>> will be re-emitted through eth1 too. > > No idea what this means. Assume a classical routing table/policy would have IP-forwarded these packets through eth2 or eth3 or would have delivered them to the local processes, I want to alter this policy so that these packets be emitted (unmodified) through eth1 INSTEAD (and not duplicated). > > >>> >>> Any idea to help me reach this goal? >>> >>> >>> Sincerely, >>> Le Testeur >> You need to read "raw" packets at eth0 and write them to eth1. > >> "man packet" will get you started. There is also a library "libpcap" >> that is used by tcpdump which you may find useful. I can hardly grasp your directions yet, but I'm heavily working on it and I thank you for your suggestions. Thought, I would prefer now to resort to such RAW features ; I'd prefer using more constrained and more secured features. > >> Robert Thanks a lot. ==> I would like you to read the post I just answered to myself to tell more to the four people who answered me about the real goal I want to reach and to demystify my needs. Thanks to do so. Sincerely, Le Testeur |
|
#8
|
|||
|
|||
|
Hello,
Ken Sims a écrit : > > On Thu, 27 Sep 2007 19:36:35 +0200, none <""testr\"@(none)"> wrote: > >>On a linux box 'A' which has interfaces eth0, eth1, eth2, eth3, I would >>like to do a special treatment on packets incoming via eth0 and whose >>source is <some-network>. >> >>I would like these packets be unconditionaly redirected unmodified for >>output via interface eth1. >> >>That is: >> - even if they were targeted (destination IP) at my box 'A', they will >>be re-emitted through eth1. >> - even if they would have been forwarded through eth2 or eth3, they >>will be re-emitted through eth1 too. > > If they would be forwarded anyway, advanced routing can be used to > force them out a specific interface. Yes. > For packets whose destination is 'A', I think you would need to do > something with netfilter to get the packets on to the forwarding > chain, but I don't know how without changing the destination IP > address. The highly controversial ROUTE target, which allows to override the routing decision, may help : This option adds a `ROUTE' target, which enables you to setup unusual routes. For example, the ROUTE lets you route a received packet through an interface or towards a host, even if the regular destination of the packet is the router itself. |
|
#9
|
|||
|
|||
|
Pascal Hambourg wrote:
> Hello, > > Ken Sims a écrit : >> >> On Thu, 27 Sep 2007 19:36:35 +0200, none <""testr\"@(none)"> wrote: >> >>> On a linux box 'A' which has interfaces eth0, eth1, eth2, eth3, I would >>> like to do a special treatment on packets incoming via eth0 and whose >>> source is <some-network>. >>> >>> I would like these packets be unconditionaly redirected unmodified for >>> output via interface eth1. >>> >>> That is: >>> - even if they were targeted (destination IP) at my box 'A', they will >>> be re-emitted through eth1. >>> - even if they would have been forwarded through eth2 or eth3, they >>> will be re-emitted through eth1 too. >> >> If they would be forwarded anyway, advanced routing can be used to >> force them out a specific interface. > > Yes. > >> For packets whose destination is 'A', I think you would need to do >> something with netfilter to get the packets on to the forwarding >> chain, but I don't know how without changing the destination IP >> address. I feared that exact same thing: AFAIK choosing an output interface implied doing some kind of DNAT. > > The highly controversial ROUTE target, which allows to override the > routing decision, may help : > > This option adds a `ROUTE' target, which enables you to setup unusual > routes. For example, the ROUTE lets you route a received packet through > an interface or towards a host, even if the regular destination of the > packet is the router itself. I'had never heard of the ROUTE target. I thank you for having pinpoint that. Anyone here can easily understand why such a target is controversial: it reverts the stages in packets processing because we usually infer the appropriate route from the expected destination IP. Furthermore, to set up a specific routing policy for some traffic that hit a particular input interface hurts our mind a bit. It's even more strange when we consider my case because it bring us four questions: - 1) Why would someone 'reflect'-out some ingoing traffic targeted at its workstation? - 2) Will these packets eventually reach the expected target. (Answer: YES, though through traffic shaping or accountancy on some other host for example) - 3) Will these packets be MANGLED on their way (i.e. using some kind of NAT) or just be re-transmitted unaltered? (Tied with question 4) - 4) What becomes of reply packets? For question 3, I think transmitting packets unaltered allows me to avoid having some other host on the network: NAT, thus mangling, would imply forward to a well known router IP. For question 4, I fear transmitting packets unaltered will imply different routes for both directions of udp/tcp flows, which would cause trouble if host 'A' serves as a gateway for some other network, especially regarding FTP and internet telephony which involve special connection tracking and NAT mechanisms. Achieving my goal with NAT, and thus with the aid of some other host (router) B, would be a better approach then. Any comments are welcome. Sincerely, Le Testeur |
|
#10
|
|||
|
|||
|
Sorry, I misread the thread and mistakenly impute your reply to 'Unruh'.
Thanks a lot for your help, thought I'm still trying to grasp it. Sincerely, Le Testeur |
![]() |
| Tags |
| question, routing, weird |
| Thread Tools | |
| Display Modes | |
|
|