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

There is room for debate. Especially with how switches deal with Broadcast / Unknown / Multicast frames. ;-)

I used to say at an old job, when a computer farts at the waste water treatment plant on the south west side of town, computers at the dump on the north east side smelled it. It was a giant L2 network.

No, switches do something decidedly different than what UUCP / SLIP / PPP / routing stacks do.

Switches effectively block or forward traffic based on a condition. Where as UUCP / SLIP / PPP / routing stacks / et al. actually modify the packets that flow through them. Also, switches are non-terminal. The others are decidedly terminal from an L2 perspective.

"Mostly" being the operative word. There are still some multi-drop installations used for special things. I've also seen traditional point to point circuits (fiber optic connections) tapped in a way that two devices can actually be connected to the circuit as a form of active / backup redundancy.

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.

ACK

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

Whatever works for you.

Yes.

I've been assuming a configuration like this.

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.

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.

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.)

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.

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

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.

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.

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.

;-)

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

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. }:-)

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

On Sun, 28 Jun 2020 22:10:33 +0200, "R.Wieser" declaimed the following:

Which is an active process -- somehow you need to implement a protocol in which one side can say "I want to transfer data to other side" AND the other side has to say "I want to receive data from the first side"... Somehow you will have to be able to specify the identification of this channel AND you will have to maintain the address translation table (source IP/Port destination IP/Port) for these packets. BUT, unlike a NAT router, you don't want the router part to initiate the gateway operation (in a router, your computer says "I want to connect to some external mode", the router takes the information (IP/Port) of the destination, swaps out the source IP/Port replacing it with a router NAT IP/Port (ie; the external/ISP assigned IP address, and some unused port on the router), and updates the NAT table. The external device then sends ACKs and return data (if any) to the IP/port the router gave it, the router than replaces its IP/port with the internal device IP/port (per the NAT table).

The external host never sees the IP/port of the internal host, only the IP/port given by the middleman router.

"Post office"/"mailbox" systems rely on buffering sent traffic locally, until the recipient connects and takes the stuff out of the mailbox.

I know of nothing that does gateway type operations but only when both external sides have issued a connection request to the middleware. You're going to have define the full protocol of this middleware, along with client software running on the external nodes to initiate the connections and handle transfer and error conditions. You will NOT have just ad-hoc (eg: any TCP/IP protocol) to go from one node to another.

NAT router... Not just a gateway (gateways don't mask IP addresses, they just forward stuff coming in on one interface that is not addressed to the local machine through to the next specified interface).

A NAT router does the IP/Port substitution, but has to maintain the status of active connections, error retries, etc. (Note that the NAT affects the "outgoing" side of the middle -- the source side still has to know the IP of the destination.

What you do NOT get is the concept that both sides connect to the middle and negotiate a connection. For that you are going to have to create a custom NAT system in which SOME type of packet says "I want to connect to some service port of some named device" [using "names" without using DNS name->IP lookups]. I say "service port" as typically the source will be asking to connect to a server running on a known port number... The source client, however, normally uses an "random" port number -- which complicates matters as the other side can't say "connect to port-X of other named device.

On Sun, 28 Jun 2020 22:22:31 +0200, "R.Wieser" declaimed the following:

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].

I largely agree.

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.

Yep. This is some of what UUCP does.

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.

Chris,

Nope, not at all. Its just one thing to consider when having to make a choice between options.

....

Thanks for the suggestion & explanation. :-)

Regards, Rudy Wieser

The OP hasn't stated exactly what applications and/or protocols are required for this "post office", but if files are sufficient, you could use OwnCloud (roll your own Dropbox). This would allow files to be kept synchronised between machines but with no direct network connection between them. The Pi runs the OwnCloud service and accepts connections from each network interface, but does not route any data between the interfaces.

---druck

That's the closest suggestion I've heard so far to using something that already exists, rather than implementing a roll-your-own solution ...

Ahem,

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. :-)

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

Grant,

Yeah, I also got that rather strong feeling, which is why I mentioned the above. To allow you to become aware of my usage of the word (and context), and invite you to mention yours. As you did.

:-) Look at the package-exchanging method I described. Although the Pi is not attempting to do /anything/ to those packets, the end result is still that the data connection (between A and C) is scrubbed. Now, tell me if that means the Pi is "passive", or "active" :-)

IOW, the definition of the word "passive" (and "active" ofcourse) is strongly tied to the context:

Using my described method to shuttle datapackets to-and-fro:

- The Pi is passive because it does not initiate connections to either A or C

- The Pi is passive because it does not attempt to alter the datapackets it exchanges between the two sockets.

- From the POV of A and C the Pi is active, as it scrubs the datastream between them.

And I'm sure I forgot a few POVs :-)

I'm sorry, but I never mentioned anything of the kind (I read that "actively decide" as "runtime" as opposed to "design time")

Also, as we are observing nomenclature, what does "traffic" mean to you ? Everything that goes over the ethernet cable (or comparable), or perhaps just the data thats left when all the different headers are peeled away ? Maybe even something in between ? And yeah, that does make (quite) a difference I'm afraid. :-)

And there you have yet another context in which "passive" or its counterpart "active" can be used. On the other hand, can you make the RPi actually /do/ anything while its "passive" (not running any kind of program) ? Other than being a paperweight of some sort I mean.

I'm going to stop this here though, this is getting silly. The next thing we do is discussing what the definition of "is" is. :-(

How do they detect that ? You seem to assume that A and C know each others IPs. Why ? What would that be good for ?

And even if they would know, there is no way they can reach each other. As you said it, if they could than this whole conversation would be moot (and a big waste of time).

Regards, Rudy Wieser

Lew,

If I would believe each 'puter can be trusted to always behave at its best, why than should I bother with putting them into different subnet, IP-ranges, VLANs or whatever ?

No, I've set up my network considering the possibility that one of the 'puters can get the flu. The groupwise isolation makes sure that not all others get infected too.

Regards, Rudy Wieser

Grant,

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.

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

:-) 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.

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

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 ?

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

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

Dennis,

I know. But you are going fully outof scope I'm afraid.

Also, I think you missed the part where I describe that both 'puters connect to the Pi - The Pi does *not* connect to the 'puters - and *especially not* to random ports.

:-) That single port access is not intended for random programs to connect to. Just /my/ program, which transfers whatever I like to another of /my/ programs receiving it on the other side.

But, if I ever want to have random programs on one side to connect to random programs on the other side (which is exactly what I *don't* want !) than I could imagine starting a "connection" with a single block of data indicating the intended target - perhaps implementing something like the "ports" scheme TCP/IP already has .... :-)

Regards, Rudy Wieser

OK this is certainly possible but not off-the-shelf behaviour, I think you should be able to persuade nc to do 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?

Ding! Ding! Ding! We have a winner.

Have yourself a virtual drink, I'm virtually paying.

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.

The Pi is is actively doing something to copy packets from one socket to another. Packets won't flow between the sockets if there isn't something doing the copy. That something is the active part.

This is also why I think routers are active. Same concept, just at an interface level vs a socket level.

Agreed.

I agree that the Pi doesn't /initiate/ the socket connections.

But as previously stated, simply establishing a socket connection from A to B and C to B is not enough. Something on the Pi must copy packets from socket to socket. Thus why I state that the Pi is actively doing something with the data on the sockets.

An analogy. Suppose that two directors in the company have a Jr. staff person go down and check their mailboxes in the mail room. The first director has the staffer take a memo and put it in the out box in the mail room and check the first directors mail box. The second director does similar. Without the 3rd employee in the mail room taking the mail out of the out box and putting it in the respective directors inbox, there will never be any mail for the staffer to pick up and bring back to their respective directors. This 3rd person, working in the mail room, is actively doing /something/ with the mail. What is being done can be debated later. But the fact remains, that without this 3rd person actively doing something with mail, communications will not flow between directors.

The Pi in your scenario is the 3rd person in the mail room actively moving things between mail boxes.

As I type this, I realize that there is a slight variation that might be what you're thinking. If the staffers put the outgoing memos directly into the recipient's mailbox (the staffers do the routing) there might not be a need for the 3rd employee. However, that is a different process than is happening above. It also requires that the staffer do more work. It also means that the staffers must have access to all of the recipient's mailboxes.

I disagree. See above. The packets (messages) don't go from one mailbox (socket) to another without the mail room employee moving them.

The mail room employee does not need to open and scrutinize the messages. Something that would be invasive and extremely active. The simple act of taking messages from mailbox (socket) 1 and putting them in mailbox (socket) 2 is an active process. It's just less active than reading and spell / grammar checking it.

That's somewhat an incidental side effect that a shoe box shaped package won't fit in a letter slot, thus gets dropped on the floor.

You have stated that only traffic of your choosing will be forwarded. That means that there is a selection criteria to make the decision of if something is forwarded or not. Given above about the active mail room employee, that is an "active decision" (per packet).

Traffic is anything that the host sends. Some of it will make it through the Pi, some of it will not. Depending on shape.

No. The Pi won't do anything productive while being passive. Even running the kernel or receiving files into a queue is a form of active action. The Pi won't do anything when it's powered off, or in paperweight mode.

Take a look at FTP and SIP for a couple examples.

You will see that FTP and SIP both want to connect to the address that's inside the data that is passed, not the address of where the apparent connection is coming from.

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.

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

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

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

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.

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.

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.

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

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

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.

Let's agree to disagree.