On Tue, May 01, 2018 at 06:08:52PM +0200, Alexander Huemer wrote: > Hi, > > I posted this question already in Jul 2017, without getting a response. > Trying again now. > > I attempt to create a network service that should be available on a host > on multiple ports on multiple transport protocols. > Since opening a lot of ports on the application layer is inefficient, I > would prefer to multiplex on the network layer, like this: > > +----- netfilter > V > > --> TCP port 1001 -->--+ > | > --> TCP port 1002 -->--+--> TCP port 1001 > | > --> TCP port 1003 -->--+ > > +----- netfilter > V > > --> UDP port 2001 -->--+ > | > --> UDP port 2002 -->--+--> UDP port 2001 > | > --> UDP port 2003 -->--+ > > [Same possibly for SCTP, DCCP, ...] > > Additionally I would like to be able to know in the application on which > port the connection reached the system originally. > > I am aware of the following mechanisms that allow what I want to do: > > For TCP: Using a REDIRECT rule with a port range and getsockopt with > SO_ORIGINAL_DST. > > For UDP: Using a TPROXY rule with a port range and recvmsg, then consume > ancillary message that is provided > > For SCTP, DCCP, others: I don't know. > > So, my question is: Is there a transport protocol agnostic way to > multiplex ports to an application, enabling the application to know on > which port the connection came in? > > I looked into libnetfilter_conntrack, though I am not sure if I can use > it reliably for that purpose, since it is not operating on an actual > socket AFAICS. > > Any advise appreciated. > > Kind regards, > -Alex Hi Alex, I think the TCP scenario is impossible. The process on port 1001 will send all responses back on port 1001, so ports 1002 and 1003 will never connect (because the TCP handshake can't complete) (SYN-> <-SYN_ACK ACK->). 2-way UDP likewise: you could perhaps implement 1-way by manglink destination port. Cheers ... Duncan. -- 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
