Using an RPi 3B+ as a "post office" between two subnets ? - Page 4

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Re: Using an RPi 3B+ as a "post office" between two subnets ?
Grant,

Quoted text here. Click to load it

Thanks.  I already got that idea too, but as I know almost nothing about the  
possibilities ...

Quoted text here. Click to load it

Well, I'm most always going for a solution that is easiest to manage and has  
the largest usage area - even when I almost certainly will never move the  
thing.  IOW, when executed my choice will be the dongle.

Quoted text here. Click to load it

As far as I can see B is in between the AB and BC networks ...

But yes, I was imagining a routing over yet another LAN segment.

Quoted text here. Click to load it

Nope, never.


Yep, that.    And to be honest, I could not care less how it happens, as  
long as they can exchange data without actually being able to connect set up  
random connections to each other.   Hence my side-step in the direction of a  
serial connection.   Data can flow, but without specially written software  
that data comes from nowhere and goes to nowhere else than from/into my  
program.

Quoted text here. Click to load it

:-) I'm quite aware of that.

Quoted text here. Click to load it

Not quite.  As I said, the port information is dropped too.  Always.

Quoted text here. Click to load it

Indeed.


Yep.  But with a small twist: In my initial idea B was truly passive.  
Receiving a connection from A would not provoke it to try to make a  
connection to C.  It would do nothing until C also connected to it.  Only  
than it would exchange datapackets.

Currently I'm cautiously sporting the idea that /maybe/ B could, when  
receiving a connection from either side, open a connection to the other side  
itself - on a fixed port ofcourse.

Quoted text here. Click to load it

Ah, I misunderstood what it might do.

Quoted text here. Click to load it

Yes, I'm aware of that.    The whole idea is that I /want/ them to  
communicate - but only on my conditions.

Quoted text here. Click to load it

I understood that.   It was just to make a point as to how far I would go to  
keep everything apart.

Quoted text here. Click to load it

Not really.   I wrote something like that a number of years ago. Text only  
though.  That was all I needed it for.  And I never actually finished the  
"automatic" part though. I would have needed a data-hash check to stop data  
storms, but eventually dropped that idea.   Instead I simply used a "send"  
button.  Served two purposes: No data storms, and being able to copy-paste  
private data without automatically having it land on other 'puters.

Regards,
Rudy Wieser



Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/28/20 3:23 PM, R.Wieser wrote:
Quoted text here. Click to load it

Fair enough.

Forums like these are good for casting a wide net and filtering through  
the catch to learn about new things that might be of value.

Quoted text here. Click to load it

ACK

I'm known among my friends as someone who frequently doesn't go for the  
easiest / simplest / fastest / cheapest solution.

Quoted text here. Click to load it

Whatever works for you.

Quoted text here. Click to load it

Yes.

I've been assuming a configuration like this.

[A]---[B]---[C]

Where hosts A and C are your two systems and B is the Raspberry Pi.

I've simply combined the letters of the systems that are connected as a  
simple identifier for the network.

  |-----|          AB network connects to systems A and B.
[A]---[B]---[C]
        |-----|    BC network connects to systems B and C.

B has an interface in the AB network and another interface in the BC  
network.

Quoted text here. Click to load it

In my diagram above:

A is connected to the AB network
C is connected to the BC network

Here's another view that might be less confusing about links.

  |-----|          AB network connects to systems A and B.
[A]   [B]   [C]
        |-----|    BC network connects to systems B and C.

Quoted text here. Click to load it

Does that mean that you will terminate the TCP connections from A /on/ B  
and initiate a /new/ connection from B to C?  (And vice versa.)

Quoted text here. Click to load it

Well, you do care.  You can use traditional routing through B combined  
with firewalling to prevent them from being able to set up random  
connections to each other.  You might not realize that you care.  But  
your statements demonstrate that you do care.

Quoted text here. Click to load it

You say that.  But said specially written software has existed in the  
Linux kernel for 20+ years.

Quoted text here. Click to load it

The /old/ port information (A to B) may be dropped.  But there is /new/  
port information (B to C) created.  You will also care very much about  
ports if you are using typical sockets and the Linux TCP/IP stack.

You may not care about ports as far as the data making it from A to C is  
concerned.  But you will care about ports in the programs that you use /  
write.

Quoted text here. Click to load it

So B is definitely going to be active in that it will be a TCP endpoint  
for A, also independently be a TCP endpoint for C, as well as actively  
copy data between the two endpoints when the time is correct.

B may not /initiate/ the connections.  But it will very much be an  
active participant in each of the connections.

Quoted text here. Click to load it

 From a networking perspective, this is somewhat simpler than the  
scenario above.  In this case, B doesn't need to participate in the TCP  
connection (windows, sequence numbers, etc.).  Instead, it can (almost)  
transparently pass the information between A and C while allowing A and  
C to deal with the minutia of TCP/IP.

Quoted text here. Click to load it

;-)

Quoted text here. Click to load it

"on my conditions" implies some sort of /active/ decision making.  ;-)

Quoted text here. Click to load it

Fair enough.

If you want to be crazy about it, you could have two pies each connected  
to their respective system, Samba, and DRBD between the Pis.  }:-)

Quoted text here. Click to load it

I still maintain that interfacing with the system clipboard on multiple  
systems is more complicated than a simple file drop.



--  
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
Grant,

Quoted text here. Click to load it

No.   It means that when A connects to B than B will do /nothing/, other  
than to wait until C connects to it   (and vise vera).

And yes, that means that /both/ connections terminate at B.

Quoted text here. Click to load it

:-) I ment that in the sense of whatever kind of (physical) connection was  
used, regardles of it being ethernet, serial, "USB bridge" or other.

Quoted text here. Click to load it

:-) Mind you, I'm attempting to connect two Windows 'puters.  But does Linux  
automatically grab a serial connection and feed it into its OS ?   Or does  
it allow me to chose if I want to handle the raw data myself ?    In the  
latter case there is zero problem.

Quoted text here. Click to load it

How is that a problem ?    How could that be used to break the isolation  
between A and C ?

Quoted text here. Click to load it

I think your definition of "will very much be an active participant" is a  
bit different from mine.    But why else do you think I would put it in  
there ?   To play paperweight ?

Quoted text here. Click to load it

Thats impossible.  All my decisions are of the passive kind !   Uninformed  
and not even thinking about how that might be a bad idea, 'cause that would  
be something active. :-p

Quoted text here. Click to load it

I think you misunderstood.    I simply copied one the (text) contents of the  
clipboard from one machine to the clipboard on another machine.  From there  
the other machine could do with it whatever it wanted.   Another KISS style  
solution. :-)

Regards,
Rudy Wieser



Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/29/20 4:37 AM, R.Wieser wrote:
Quoted text here. Click to load it

I've gathered this understanding by now.  But I don't recall where the  
multi-threaded parallel highly latent discussion was when I wrote what  
you replied to.

Quoted text here. Click to load it

This means that B is active in the connection on many levels.  Including  
needing something to copy data between the independent connections.

Quoted text here. Click to load it

I largely agree.  But you do care /some/ amount greater than zero  
because of your comments about speed.  ;-)

Quoted text here. Click to load it

It doesn't really matter what the A and C devices are, much less what OS  
they are running.

Quoted text here. Click to load it

Let's elide the typical serial line signaling requirements for now.

The data will come in the serial port and be available at a TTY device;  
e.g. /dev/ttyS0 or /dev/ttyS1.

That data will sit in buffers until something reads it.

So, yes, data does come in and wait for something in the OS to use it.

The typical serial line signaling requirements would prevent the source  
from actually sending.  But the fact that something does want to send is  
made available to the OS and programs thereon.

Quoted text here. Click to load it

You choose to take it from the TTY device and do what you want with it.

Aside:  Data will not flow between TTY devices on it's own.  You must  
have something actively copy the data between them.

Quoted text here. Click to load it

It most likely can't be used to break isolation.  But it is something  
that the Pi needs to keep track of and deal with.

Quoted text here. Click to load it

You have been quite adamant that the Pi is passive.  And here you are  
almost acknowledging that it's active.

Quoted text here. Click to load it

Na.  The Raspberry Pi is fairly light and doesn't make a good paperweight.

Quoted text here. Click to load it

You have indicated that there is criteria for what is and is not passed  
between A and C.  Executing that criteria is an active process.  There  
is at least one logical condition in it.  Executing / walking /  
performing that logic is an active process.  It is more than blind  
packet in packet out behavior.

Quoted text here. Click to load it

Let's agree to disagree.



--  
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
declaimed the following:


Quoted text here. Click to load it

    They can't, unless you configure each to be a routing gateway for the
other -- that's what "internet connection sharing" on a Windows box is
doing (and whatever the equivalent on Mac/Linux would be).

Quoted text here. Click to load it

    You still aren't clear on WHAT this communication IS... File transfers
to the R-Pi with no knowledge of any other systems... FTP/sFTP both require
the external systems to connect to the R-Pi to move files between them and
the R-Pi -- they do NOT move files /through/ the R-Pi to other external
systems.

    NFS/Samba is similar -- in that whatever "share" (a directory on media
mounted on the R-Pi) is made network shareable. The difference is that
FTP/sFTP requires explicit GET/PUT operations to move files around, while
network shares are "mounted" on each external device and whatever native
file manipulation commands are available can be used (including editing
files that on the share).


--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: Using an RPi 3B+ as a "post office" between two subnets ?
Dennis,

Quoted text here. Click to load it

Ah.  The answer to that is simple: Anything I want.    Datapackets normally  
do not care what they contain. :-)

And that is all I intended the connection with the RPi as a middle-man to  
be: To be able to send data either way, but without either of the two sides  
being able to see each other.   No more, no less.

Regards,
Rudy Wieser



Re: Using an RPi 3B+ as a "post office" between two subnets ?
On Sun, 28 Jun 2020 22:22:31 +0200

Quoted text here. Click to load it

    OK so take it step by step. First achieve the necessary physical
connection then decide on what mode of data transfer you want to permit.
Examples:

    Machines on A or B can place files somewhere where they can be seen
by both A and B. Solution Samba and/or NFS. Obvious variations where A and
B have separate writable areas.

    Machines on A and B can have a variety of secure file drops that
they can make available to machines on A or B selectively - sftp or
similar, but you can torture Samba into it if you are good at Windows
networking.

    Machines on A can reach selected services on B (and vice-versa) via
a proxy on the Pi - the proxy can be as simple as a firewall based packet
forwarding service or as complex as squid.

    Any combination of the above.

    The Pi provides the illusion of a transparent connection between A
and B but in reality intercepts, filters and potentially modifies any and
all traffic between them. This is done with the firewall capabilities of
Linux and is as complex as you want to make it plus about 10% usually.

Quoted text here. Click to load it

    The devil is in the details - the ones above are just a handful of
examples that sprang to mind. The main thing is you need the physical
connections working so that you can ping the pi from either network. Nothing
else happens until you make it but that's the starting point upon which all
the rest is built - so get that going first while you work out exactly what
you want to try and pull off first - it's all possible, it's all open
source and some of it is a tad fiddly.

--  
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.
Re: Using an RPi 3B+ as a "post office" between two subnets ?
Ahem,

Quoted text here. Click to load it

Not quite.   My basic idea was/is to have the Pi to respond to a connect  
request on a single port only, and than, when both sides have connected  
(their actions, not the Pi's), transfer datapackets from one interface  
(socket) to the other.

Yeah, its an absolute minimal approach.   Any-and-all "filtering" is  
actually done as part of a sockets normal behaviour. :-)

Quoted text here. Click to load it

I mentioned somewhere earlier that I have my reservations about that kind of  
filtering.  To easy to forget to exclude a port or not filter certain data  
and you're SOL..

But yes, its also something to look into.    Heck, there is /so much/ I can  
look into that I really need to secure myself a life extension to visit it  
all ! :-)

Regards,
Rudy Wieser



Re: Using an RPi 3B+ as a "post office" between two subnets ?
On Mon, 29 Jun 2020 10:14:09 +0200

Quoted text here. Click to load it

    OK this is certainly possible but not off-the-shelf behaviour, I
think you should be able to persuade nc to do it.

--  
Steve O'Hara-Smith                          |   Directable Mirror Arrays
C:\>WIN                                     | A better way to focus the sun
We've slightly trimmed the long signature. Click to see the full one.
Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 29/06/2020 01:23 pm, Ahem A Rivet's Shot wrote:
Quoted text here. Click to load it
Computers [A]----[Pi]----[B]
              seg1    seg2

Assuming A connects to the Pi (segment 1) and triggers the response, how  
does B know it has to connect to the Pi (segment 2) to receive the data  
packets?


--  

Chris Elvidge, England

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/29/20 2:14 AM, R.Wieser wrote:
Quoted text here. Click to load it

That's why a best practice with firewalls is to white list only what you  
want to allow through and carte blanche block everything else.



--  
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
declaimed the following:

Quoted text here. Click to load it

    Which implies you have defined a protocol and CLIENT programs running
on the "sides" to talk to that port. The R-Pi is listening for connections
-- making it a /server/ application. The "sides" need to have client
applications that ask for that port. Client programs that use other ports
won't connect -- so you can't use the R-Pi to, say, tunnel TELNET from one
"side" to the other "side" as TELNET uses port 23 as the server side.

https://www.man7.org/linux/man-pages/man2/listen.2.html
https://www.man7.org/linux/man-pages/man2/accept.2.html

    The R-Pi would have to be listening for any connection requests on the
known port -- but likely from any interface. You then accept that
connection which creates a new socket with R-Pi and "other" end-points. You
also need to multi-thread passing that new socket off so the main server
can go back and process the next listen/accept sequence. But now you have
two sockets (and if you are listening on "any" interface, both accepts
could be to the same "other", just with different end-point port numbers).
How you identify that these two accepted sockets are supposed to be
forwarding packet data between each is something you will have to write.

    The whole TCP/IP system is based around one (client) side initiating
connections all the way through to the remote (server) side (and servers
that spawn threads for each connection in order to allow them to go back
and accept more connections)..


--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: Using an RPi 3B+ as a "post office" between two subnets ?
Quoted text here. Click to load it

That's a pretty good description good - now read Stevens book on unix  
networking programming (other books are available) and write your  
program!

I can't see what's stopping you.

Sometimes I think you enjoy more discussion instead of actually googling  
around/reading and getting the job done.

There's a newsgroup for unix programming where are more specific  
questions can be asked.

And before you say anything - in this context "unix" = "linux".

Quoted text here. Click to load it

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/29/20 2:01 PM, Jim Jackson wrote:
Quoted text here. Click to load it

~chuckle~

"in this context"

I wouldn't argue with that even if I could.  ;-)



--  
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On Mon, 29 Jun 2020 10:14:09 +0200, "R.Wieser"

Quoted text here. Click to load it

That sounds like a message queue, have a look at mosquitto /
mqtt. It supports all kinds of restrictions (e.g. users can only
access certain topics, client certificates).
An MQTT broker can have multiple listeners on multi-homed
systems like you envision B to be.

A publishes a datagram to the broker running at B, C subscribes
to A's topic and receives it when there is one.  
And the other way around.  
It is store-and-forward by nature, A and C can be online at the
same time, but they don't have to be.

Use iptables to only allow mqtt ports, and/or to restrict the
source and destination networks.
--  
Kees Nuyt

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/28/20 2:22 PM, R.Wieser wrote:
Quoted text here. Click to load it

"normally" is the /operative/ word.  FTP and SIP are two off the cuff  
examples of protocols that /do/ care /greatly/.

Quoted text here. Click to load it

There are a lot of ways that this can happen.  Layer 2 messing with MAC  
addresses and / or Layer 3 messing with IP addresses and / or Layer 4  
messing with TCP (et al.) sockets and / or Layer 7 messing with  
application layer data.



--  
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
declaimed the following:

Quoted text here. Click to load it

    Data packets may not care what they contain, but the addressing is
crucial. Servers wait on KNOWN ports for clients (using random assigned
ports) to connect. Once connected, those servers expect the data packets to
contain data conforming to some defined protocol (sending an SMTP formatted
email message to a server on port 80 is not going to work -- port 80 is the
standard for HTTP formatted messages).

    This is where your "A connects to B", "C connects to B", and now data
flows falls apart. Especially if "A" connects to "B" twice (say two
different programs want to transfer different data to "C"). Both
connections are made to the single server port on "B". How does "C" make
two connections to "B" and /somehow/ identify WHICH connection from "A" it
means expects (or vice versa, if "C" makes to connections to "B", how does
"A" identify which one it wants to connect with).

    And again, since you are connecting to a single known port on "B" --
you need to provide clients on "A" and "C" that can then handle whatever
data is being passed between them.

    The only scheme that truly keeps "A" and "C" from knowing details about
each other is the file drop/mail box scheme, in which "A" connects to "B",
transfers a file into a mail box directory for "C" (it may know some name,
if you have multiple nodes on each side, as it needs to access the node
specific mail box/directory) and "C" connects to "B" to read the mail box
(and if needed drop files into the box for "A").

    Avoiding C reading before A finishes writing requires some upper level
convention -- such as using some special file extension during the write,
and after the write completes do a rename operation. The other side is not
supposed to read files with the special extension. OR -- you first write a
lockfile (contents don't matter, just that the name is the actual file +
some extension). If lockfile is seen, do not read file without the
extension. Both styles do have a problem -- if a process on the sending
side fails before the rename, or the lockfile deletion, one has dangling
files in the mailbox (a CRON job that checks, say, every three hours for
lockfiles that are 6 hours old or older could delete the lock [unless you
have transfers that take more than 6 hours] or just delete the file with
the special extension [presumes B can't know what the real file extension
is supposed to be].


--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/28/20 9:58 PM, Dennis Lee Bieber wrote:
Quoted text here. Click to load it

I largely agree.

Quoted text here. Click to load it

Though it is hypothetically possible that some of the addressing can be  
moved to inside the data.  Thus hypothetically it could be made to work.  
  But it would be extremely atypical and custom.  There would also be  
multiplexing issues.  Can they be overcome?  Probably.  Though I  
question the practicality of doing so.

802.2's SSAP / DSAP (collectively known as LSAP) comes to mind.

Quoted text here. Click to load it

Yep.  This is some of what UUCP does.

Quoted text here. Click to load it

Another trick is to have the file, with a specific naming convention /  
extension be the lock file.  Once the write is complete, rename or move  
the file, so that it is ready to be found by a specific naming convention.



--  
Grant. . . .
unix || die

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On Sun, 28 Jun 2020 23:39:49 -0600, Grant Taylor


Quoted text here. Click to load it

    Except, from your examples, the source is still requesting a route to
the final destination -- which the OP seems insistent is not viable for
him. He wants both sides to only address the R-Pi in the middle, and they
must each initiate the connection /to/ the R-Pi.

    Which, even with UUCP, comes down to the source connecting/passing the
data to the R-Pi only, and the destination also using UUCP for
connecting/fetching the data from the R-Pi. So... again we have the R-Pi as
a file drop/mail box and UUCP/NFS/(s)FTP are essentially equivalent in
functionality. Files are transferred into some storage on the R-Pi -- there
is no real time packet transfer from one machine to the other (and
especially no ad-hoc protocols).

    What the OP wants is almost the reverse of a VPN where both sides are
treated as part of the same local/private network, with connections
tunneled through the unsecured public network to a VPN server.


--  
    Wulfraed                 Dennis Lee Bieber         AF6VN
     snipped-for-privacy@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/

Re: Using an RPi 3B+ as a "post office" between two subnets ?
On 6/29/20 1:43 PM, Dennis Lee Bieber wrote:
Quoted text here. Click to load it

I think we are in agreement.

Though I think we have different understandings of what's going on.

Both A and C initiate a connection to the R-Pi (B).  UUCP transfers the  
files on our behalf.  It uses a directory structure with multiple  
sub-directories as queues for the destination system.  Both A and C pull  
files from B if there are any queued for them.

I think what is and is not acceptable to the OP is somewhat of a  
quagmire and difficult to say with any degree of certainty.  I think  
there are two things that the OP would like, and they are somewhat at  
odds with each other, at least in how they achieve a common overarching  
goal.

The only thing that I think UUCP falls short on is the fact that A and C  
know that they are talking to the other and that it is by way of B.  
But, based on my current understanding of the OP's desires, I don't  
think this is really a /problem/ so much as it is a strong /desire/.

I honestly believe that UUCP does bring much in the form of a solution.  
I wouldn't have suggested it if I didn't think so.

Quoted text here. Click to load it

One big leg up that UUCP has is that it is an established mechanism for  
dealing with this, retrying, multiple systems, and does not require any  
form of solutioning.  Others at the very least require defining and  
managing a queue structure.  I also question how well things will deal  
with the R-Pi (B) NAS being unavailable when they want to push new files  
or poll for / pull queued files.

Quoted text here. Click to load it

Sort of.  But much more restrictive.  And without relying on a firewall  
to impose that restriction.



--  
Grant. . . .
unix || die

Site Timeline