[Dxspider-support] DXSpider multiple calls with same IP.

[Dirk Koopman]

Many nodes that have an external address actually are located on a DMZ  
or other network with, for example, rfc1918 addresses. There is a 
pinhole or reverse address translation mapping to get from outside to 
that internal node / port. If a user connects from outside, it will come 
into the node on the DMZ with its external source intact. Any spots that 
user on the outside makes will have their  external address used. There 
is no problem. Otherwise getting on for 80% of the cluster would be 
having issues.

No, the real problem comes with arrangements that connect to another 
program (I will use the term "webcluster", loosely, from now on) that is 
also pinholed or reverse proxied onto a program that also located on 
that (or indeed some other) DMZ. We have now have two programs that 
communicate together just on that DMZ (or just internally) using 
'internal' addresses. There is now no direct IP link between the 
webcluster user and the node.  The intrinsic information that is 
available from the IP addresses on a direct NATed external->internal 
node connection can be (or often, it seems, is) lost for any user 
connecting to the webcluster (if care is not taken). The only 
connection, such as it is, is user-->webcluster->node and vice-versa.

There are ways of dealing with this, one in the user command interface 
or, a more general and sophisticated way, by connecting webcluster and 
node through a basic PC protocol connection. Oh, or the coming third way.

Most webclusters use the user command interface, which is usable but 
(but in my view) more complicated and more limited than the second 
method. This interface allows the webcluster (using its callsign) to add 
both the 'by <call>' and 'ip <ipaddress>' keywords to the normal user 
mode 'dx <qrg> <call> [<comment>]' spot submission to the node. This is 
provided that the sysop of the node has given the webcluster callsign 
sufficient privilege level.  There is no equivalent for other commands 
like announces, chat etc etc. This means that any outgoing spot 
submitted through the webcluster will pop out of the node with the 
user's call and IP address intact. An example might be: 'dx 7001 oh5zz 
ip 82.68.205.1 by g1tlh test tes tse etc'

The second way allows one to send spots as PC61s and announces etc as 
PC92s after a very small startup exchange on first connection, that also 
means that one can get the same back from the node, no privileges need 
be messed about with etc. Instead of a user dx command (like the one 
above) you send 'PC61^7001.0^OH5ZZ^15-Mar-2023^2242Z^test tes tse 
etc^G1TLH^GB7TLH-2^82.68.205.1^H99^', the node will just distribute that 
as a normal incoming spot to all its users and nodes in the normal way. 
The webcluster is already managing its users and their state, so the 
node does not need get involved with that at all.  Any PC sentences that 
the node sends the webcluster, that it isn't interested in (anything 
other than PC61, PC11, PC93 and probably PC41) can simply be dumped. Or 
in the future, maybe I could establish 'classes' of 'nodes' where I 
limit what that class of that node-like connection sees in PC Protocol - 
meaning I just send you what that class wants. Or, thinking aloud now, 
you could just tell the node which PC sentences you want.

So that is now(ish).

Sometime in the (hopefully very near) future, when I can step back from 
firefighting idiots, the next method will become available: websockets. 
It will be possible to reverse proxy into standard websocket on which 
will certainly be a standard [user] command interface - but other 
interfaces could be done - [a matter for further discussion].

This is actually the opposite way of looking at modern websites, but 
then we will be starting from the inside out anyway. In order for an 
external entity (user or webcluster) to get a websocket, there has to be 
a website active in the node - a websocket has to have a URL. So, 
inevitably, to get a websocket a basic website has to be available to 
serve that websocket URL (if nothing else).  As you have to have that 
webserver anyway as part of the node, if were skinnable (it will be) - 
that skin could be constructed with, and use, any of the fabulous things 
that the Mojolicious webapp system provides - then one has a web cluster 
which could handle 1000s of users. All in one 200-400MB process.

Just (a bit more than) a thought...

73 Dirk G1TLH

P.S. It really was not some random chance that I started using the 
Mojolicious system.

On 15/03/2023 21:51, Lee Sawkins via Dxspider-support wrote:
> The problem is when non local users of clusters enter DX spots and have their own IP Address replaced by the cluster's IP address.  This results in all users of some clusters all showing the same IP address.
>
> Lee VE7CC
>
> ----- Original Message -----
> From: "Kjell Jarl" <kjell.jarl at bahnhof.se>
> To: "The DXSpider Support list" <dxspider-support at tobit.co.uk>
> Cc: "Lee Sawkins" <ve7cc at shaw.ca>
> Sent: Wednesday, March 15, 2023 9:31:12 PM
> Subject: SV: [Dxspider-support] DXSpider multiple calls with same IP.
>
> Hi
> I am not sure about that. I, being on my local interface (192...), will appear with IP address of the dxspider server when spotting, I don't remember seeing that presenting a problem.
> 73 Kjell SM7GVF
>
> ---- Lee Sawkins via Dxspider-support skrev ----
>
>> I thought it was decided that sending out spots with the IP address of the Cluster Node was a bad idea.
>>
>> _______________________________________________
>> Dxspider-support mailing list
>> Dxspider-support at tobit.co.uk
>> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support
> _______________________________________________
> Dxspider-support mailing list
> Dxspider-support at tobit.co.uk
> https://mailman.tobit.co.uk/mailman/listinfo/dxspider-support