On 7/4/2008 12:22 AM, Elison Niven wrote:
I'd just like to clarify a few things I should have done before.
1) Eth0 and eth2 will always be in different subnets.
Ok.
2) All RTP traffic that has to be sent to the DSPs will always arrive
to eth0.
Ok.
Eth2 is an internal IP address. The system is known only by one IP
address to the outer world - that of eth0.
*nod*
Consider an example: My System's IP is eth0 - 192.168.1.50, subnet
mask - 255.255.255.0 Eth2 (internal) is 192.168.2.50, The DSPs are
192.168.2.51 to 192.168.2.58, subnet mask - 255.255.255.0 The default
gateway of the DSPs is eth2 - 192.168.2.50.
This is simple enough.
There is a voice call from another device at 192.168.1.100 to
192.168.1.50.
Outside the system, the following transfers are visible (say in
wireshark/ethereal):
192.168.1.100 --> Sends RTP:
src IP = 192.168.1.100
dest IP = 192.168.1.50
src port = 8000
dest port = 10000
My system 192.168.1.50 --> Sends RTP:
Src IP = 192.168.1.50
Dest IP = 192.168.1.100
Src port = 10000
Dest port = 8000
Ok. This is the request and the reply (if you will) as seen when
sniffing the cable connected to eth0 of your system.
Inside the system, the RTP is actually generated by the DSPs, say
DSP1 here.
DSP1 --> Sends RTP:
Src IP = 192.168.1.50 - This is IP spoofing. DSP1's actual IP is
192.168.2.51. This is the IP as seen in the source IP field in the IP
header.
Dest IP = 192.168.1.100
Src port = 10000
Dest port = 8000
This traffic is received on eth2 and must be sent out through eth0.
The purpose of faking the IP is not to have to do SNAT on such
packets.
You can do the source IP spoofing here, but I would not recommend it for
multiple reasons.
- You will have to (re)configure all the DSPs with the IP of eth0 if
it ever changes.
- This could conflict with reverse path filtering on your system.
- IMHO this is bad form.
- If the DSP wants to communicate with your system it will have to use
a different source IP, or other trickery will have to be done to allow
your system to communicate with the DSP.
- SNATing is not going to be that much of a load.
The traffic that the other device is sending is received on eth0.
Such traffic is forwarded to DSP1.
Ok.
Each of the DSPs also sends control packets that are always sent as:
Src IP = DSPs actual IP address = 192.168.2.51 Dest IP = eth2 =
192.168.2.50
Ok.
Such packets need to be sent to a local process on the CPU.
By standard routing and socket binding this will be inherent.
So I guess the minimal rules needed will be:
1) For packets received on interface eth2
IF Destination IP != eth2 IP THEN send the packet out from eth0 ELSE
send it to the CPU
This is not a rule. This is standard routing / forwarding. If a packet
coming in to an interface has a destination IP belonging to the system,
it will be processed by the system. If a packet coming in to an
interface has a destination that does not belong to the system it will
be forwarded as long as forwarding is enabled.
2) For packets received on interface eth0
Now the system will be listening for http, telnet and ftp connections
on their fixed port numbers. The system will also be listening for
SIP connections to a fixed port - say 5060. Such packets obviously
need to be sent to the CPU. Does that mean I have to check the
destination port number of all the packets received?
IF Dest port of packet == 80 (http) OR 21(ftp) OR 23(telnet) OR
5060(sip). (Does this becomes a single rule or more than one?) THEN
send packet to the CPU ELSE goto below rules
No. Again, any packets coming in with a destination IP belonging to the
system will be passed up in to the system for processing.
For all other packets received, the rule will be (for the example
above):
IF Source IP == 192.168.1.100 and destination port == 10000. Again
does this become 2 different rules? If I also check the source port
of the packet here, will that add a new rule? THEN send the packet to
DSP1. This will require a DNAT I think. ELSE drop the packet.
This is one rule with multiple conditions to it. If this or other rules
are not matched, have a final rule or chain default policy to drop the
packet.
Now I intend to (horribly) support 256 such calls and I need to
figure out the minimal rules that would be required.
Can you provide a list of source / destination IPs and ports or a
pattern there of? I'll look at it and see how many rules I think would
be needed (with and with out the optimizations that I spoke of).
(Ofcourse, I see above that there would be some (don't know how many)
problems when an external device with IP = 192.168.2.51 wants to talk
to my system, But we'll get to it later.)
Heh. This is another reason why I suggest that you not have your
external IP configured on the DSPs because if you need to change it, you
will have to change configs on your DSPs too.
Now this brings up a question as to whether this is a config for a
specific install or if this is to be more dynamic and installed a bunch
of places. If it is the former corners can be cut, but if it is the
later, care should be taken to take these types of things in to account.
Grant. . . .
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
