Adding a fd that is not obtained through accept to the list the active connections
ottavio at campana.vi.it
Tue Aug 31 19:18:33 UTC 2021
an ssh tunnel is not compatible with the specs of the ONVIF uplink service.
I understand that there is no "free lunch" to achieve this, thus I expect
to have to write code. What is the suggested way to add a connection, by
passing the fd of the connection to nginx before establishing the SSL
context. Where could I hook up? How can I implement a fake listener that
does not listen but connects to a remote server?
Il giorno lun 30 ago 2021 alle ore 13:24 Phillip Odam <
phillip.odam at nitorgroup.com> ha scritto:
> Hi Ottavio
> There’s no solution just with nginx as it currently that I know of, to
> avoid the need for a port forward in the NAT router a simple solution would
> be to use a ssh tunnel - this does separate initial connection from
> subsequent requests as you’re unlikely to want to establish a new tunnel
> for each and every request and ‘knowledge’ the connection is established is
> no longer inherently part of the application making the HHTP request. So to
> simplify things you could just expect the ssh tunnel to be established as a
> precondition (once off initial setup)
> On Friday, August 27, 2021, Maxim Dounin <mdounin at mdounin.ru> wrote:
>> On Fri, Aug 27, 2021 at 01:59:03PM +0200, Ottavio Campana wrote:
>> > Dear Phillip,
>> > I know Tailscale very well, I use it and like it a lot. But my final
>> > is finding a way to implement the ONVIF Uplink service,
>> > https://www.onvif.org/specs/srv/uplink/ONVIF-Uplink-Spec.pdf , where I
>> > have several devices on the LAN that need to connect to a remote server,
>> > which will then send commands.
>> > Therefore I need a way to start a connection from nginx (or an external
>> > program and then passing the fd through a unix socket domain) and make
>> > act as if the fd were obtained from an accept.
>> > Nginx works with events and I find it very difficult to find a
>> mechanism to
>> > pass this connection to it.
>> > Do you have other ideas?
>> The most simple solution I can think of is to open two
>> connections: to your command endpoint and to nginx, and proxy
>> everything once the connections are established.
>> Maxim Dounin
>> nginx-devel mailing list
>> nginx-devel at nginx.org
> nginx-devel mailing list
> nginx-devel at nginx.org
Non c'è più forza nella normalità, c'è solo monotonia
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx-devel