BIND_TO DEVICE and the loopback interface

BIND_TO DEVICE and the loopback interface

Gilad Ben-Yossef gilad at codefidence.com
Fri Jul 3 11:44:43 IDT 2009


Hello List,


A friend presented me with a difficult problem which I don't have a 
solution for and I thought someone here on the list might have an idea.


The problem is as follows:


You have an application running on a machine that has two network 
interfaces. One for management and one for media.


You have a network server application (it's a SIP UA but that doesn't 
matter much) that is bound to an IP on the media network interface. 
Because the media and management networks might be completely different, 
you use the BIND_TO_DEVICE socket option om the server sockets so that 
the kernel will only route traffic for that socket via that device.


Normally, the clients that speak to the server are outside the machine 
and sit on the media network, and everything works.


However, there is one exception - you have a single client which runs on 
the machine itself that needs to talk to the server. The client tries to 
connect to the server IP, but since all IP traffic inside the machine is 
automatically routed via the loopback network interface (lo), and since 
the server forces the kernel to only route traffic via the media 
interface, we have a routing failure and the client can't talk to the 
server. However, if you were to remove the server BIND_TO_DEVICE and 
everything works.


Required: a solution, generic as possible, extra points for no need to 
change server and client apps :-)


Already suggested and reject by my friend:


> OK, I found a solution. It does require some work but it'll do the job:
>
>  
>
> You will need to hijack the socket, bind, connect (for TCP) and  
> sendto, recvfrom (for UDP)  C library calls.
>
> See 
> http://tuxology.net/2008/05/15/forcing-connections-through-a-specific-interface/ 
> for an example of how to hijack the library calls.
>
>  
>
> Using these hijacked library calls, whenever the application opens a 
> socket, you create another shadow socket which is not bound to the 
> outside interface. Then for each bind/connect/sendto and recvfrom 
> call, use the appropriate socket (bound to device or otherwise) 
> according to the destination - external or internal.
>
>  
>
> Since the hijacking is done by writing an external library and forcing 
> the application to load it by setting an environment variable, no 
> changes to the application is required.
The reason for rejection is:


> There will be a clash if 2 instances of the application use the same 
> port...


The solver will win fame and my eternal gratitude. :-)


Is there anyone up for the challenge?


Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker & CTO
Codefidence Ltd.

Web: http://codefidence.com
Cell: +972-52-8260388
Tel: +972-8-9316883 ext. 201
Fax: +972-8-9316884
Email: gilad at codefidence.com

Check out our Open Source technology and training blog - http://tuxology.net

	"Now the world has gone to bed
	 Darkness won't engulf my head
	 I can see by infra-red
	 How I hate the night."

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20090703/49e36cb6/attachment.html>


More information about the Linux-il mailing list