What are you doing !? You're spoiling my game ! :-)
:-p
Yeah, and thats part of the problem. Its not the first time I notice that people often, without as much as a thought, going for 10-pound solutions to hammer a quarter-of-an-inch problem in. It might work, but don't look at the side effects.
It was always my full intention to use the RPi's full TCP/IP capablilities, with me just requesting or writing data (and the socket taking care of the rest). I just wanted to make sure that the datastreams from the two networks would stay seperate.
Well... Long ago people wrote messages on /paper/, put them in an also paper "envelope" and .... No, really! :-)
But seriously, in this context I tried to indicate a place where one host could drop a message, and the other could retrieve it - without them ever needing to meet. I just didn't want to be more specific than that - simply because I had no idea what could/would already be available.
On Sun, 28 Jun 2020 11:54:16 +0200, "R.Wieser" declaimed the following:
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).
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
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Of course it can, each link is point to point but nothing restricts a computer to a single serial port. Way back we used to use Altos Micnet to create a LAN based on UUCP over whatever topology of serial connections you cared to make. These days PPP would be a much better option.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
The problem with all those is that activating Wi-Fi overrides the Ethernet, but the others are active. As far as Windows is concerned there are FIVE NICs on this machine.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
Seeing as how you are wanting to do something akin to a proxy for TCP traffic, I would suggest that you use a USB-to-Ethernet dongle for a 2nd Ethernet interface.
As others have stated, a Layer 2 managed switch using 802.1Q VLAN tags is a perfectly viable option too.
Which you use will probably depend on what you have available and / or want to purchase.
I suspect that USB will actually be faster than any hat that uses GPIO pins. I could be wrong about this. But I would bet a cup of coffee.
A routed network doesn't necessarily mean that there is something in between the networks.
|-----| Cable 1 / Subnet A [A]---[B]---[C] Hosts A / B / C |-----| Cable 2 / Subnet B
A would have a route to the BC network via B (AB interface) C would have a route to the AB network via B (BC interface)
You can also use a default gateway instead of more specific routes. But that's more minutia of what the route is. What it does is still functionally the same thing.
That assumes that A and C are addressing packets to each other.
There is another possibility, which I call a "Customer Interface Router". Typically seen where a non-small business (think national paint brand) interfaces with a bunch of small outlets that they interface with in such a way as to not have to complicate the big network with routes to all the smaller networks. Or conflicts between the smaller networks.
The C.I.R. NATs both the source and destination addresses of traffic flowing both ways through the C.I.R. The parent company can send printer traffic to the C.I.R. and C.I.R. will then alter the traffic so that it is now to the printer and from the C.I.R. Similarly, someone in the small office can open a terminal connection to the C.I.R. and the C.I.R. will alter the traffic so that it is now to the corporate server and from the C.I.R. Neither the parent company nor the small subsidiary need to know anything about the others network (beyond what's needed to configure the C.I.R.). They both simply talk to the C.I.R. This type of setup is typically done with NAT.
But another option is an application layer gateway / proxy. Host an LPR server (daemon) on B / the C.I.R. and have it actively be part of the printer path. Likewise with the terminal server.
So, which is better. It depends. NAT can usually be done with relatively simple devices (comparatively) than a full Application Layer Gateway / Proxy. But, the ALG / Proxy usually gives more (filtering) capability.
Geography and physical locality actually have very little to do with it. Intermediate networks are /easier/ but are not /required/. It's possible to have the /same/ network spread around the globe.
Okay. - I think we need to zoom in a level.
Do you want A and C to be able to establish TCP connections with each other? E.g. through a router of some sort?
Or do you want A to *ONLY* be able to establish a TCP connection with B, and likewise with B & C? - Note: This is independent of what B does with the traffic from the established TCP connection.
Aside: The same can be said about UDP and other protocols on top of IP. But I'm focusing on TCP for this discussion.
This may seem like a minutia difference. But it is a very important difference. If you're okay with A and C establishing a TCP connection with each other through an intermediate router (B), then much of this conversation is moot. Like a mic drop.
If you want A and C to not be able to establish a TCP connection with each other in any way shape or form, then we do need to continue talking about other options.
Now you're talking more about something between NAT and an ALG / Proxy.
You don't even need Samba / NFS / etc. on the intermediate host B.
A will /think/ that it's talking to B when in fact it's /really/ talking to C. Likewise, C will /think/ that it's talking to B when in fact it's /really/ talking to A. It's just that A and C will have a different idea of what each other's address is.
It's important to note that A can still send traffic to C, via B, that is malformed and potentially attack C. And vice versa.
This is one of the things that the intermediate file drop helps avoid. Network level attacks are effectively moot. There is no network communications between A and C when using a file drop.
No. Not as such. UUCP works by running a command on A that tells UUCP on A, B, and C, to transfer the file to C.
A$ uucp /local/file/path B!C!/remote/file/path
Much like you could use the cp or scp command.
UUCP on A, B, and C, then do their thing to transfer the file between A and C via B on your behalf.
I have some concerns about Samba, particularly the NetBIOS Session Service (NBSS) which ? as I understand it ? is intended to do exactly that. But that doesn't mean that you actually have to use the NBSS functionality.
Network Attached Storage (NAS) file drops ? or "post office" ? generally only provide a place that A or C can put files for the other to pick up.
Remember, even a file drop, can enable programs on A and C to communicate with each other. Much like we are ""interactively communicating with each other through Usenet. It's just highly latent compared to a more typical TCP connection.
A true file drop / post office has the advantage that the file is written (by A), something (on B) can check it and only move it to where the other (C) can get it /if/ it passes muster. This typically means that only specific /known/ to be good types of communications are allowed. Such a filtering file drop will detect and block abnormal communications.
NAT quite likely can't do this type of filtering.
An ALG / Proxy might be able to do this type of filtering.
You only install Samba once. You only need to run one instance of it. (In fact, running multiple instances of Samba used to be quite difficult.) The same single instance would listen on multiple interfaces.
Agreed.
Because you have a couple of systems from different 3rd party vendors that you want to exchange files but the current configuration doesn't allow it and the vendor(s) won't reconfigure things without paying (a lot of) money.
Because you want to go between systems that don't speak a common protocol. Say NCP on one side and IPv4 on the other. Or IPX and AppleTalk. Or DECnet and NetBIOS. ;-)
I honestly don't need anything stronger than that.
True.
Fair enough.
I was thinking industry standard news and email servers & clients on each end exchanging files through the intermediary.
There are a lot of ways to solve this problem.
Now you're talking about something a LOT more involved. Many traditional remote control applications support this. But I'm not aware of any that will work without an established network connection of some sort. I'm betting virtually none of them will work through a pure file drop / post office communications mechanism. Save for writing the clipboard contents to a file, transferring it, and loading it on the other end.
You just said what I said. "Each (RS-232) link is point to point". End of story.
I completely agree.
But now you are talking about something decidedly outside of the scope of "each link". ;-)
Sure. That's the software that interconnects multiple machines on top of many point-to-point links.
RS-485 supports physically connecting more than two machines to the same physical link. No additional software needed to copy things from link to link. ;-)
I think we have different understandings of what "data diode" is and does.
To me, a "data diode" is a one way flow control device (much like the electrical component that only allows current flow in one direction).
When you start talking about conditionally allowing data to flow or not flow (in one or both directions) you start getting into a firewall that filters traffic based on IP and / or protocol and / or port and / or state.
This sounds more like a firewall combined with a "data diode".
Agreed.
There are many ways to achieve this simple data drop / post office functionality.
Now you get into multi-user access to the data drop / post office and what they can see (read) / modify (write) / delete (also write). This quickly devolves into a deep and dark rabbit hole.
Yes, this the basic operation of a queuing mechanism.
I can think of an all-ethernet way of making the RPi a drop-box service between two unconnected networks, but it might not suit your criteria. Nevertheless, here it is.
1) the Linux networking stack can support multiple IP addresses on a single physical ethernet interface. These addresses /do not/ need to belong to the same subnet, or even the same network.
2) the Linux networking stack can be configured to act as a "host" (rather than a router), ensuring that the system isolates each network so that packets are not exchanged between any of the connected networks.
Taken together, this means that you can connect a generic Linux system to /both/ of your networks, and ensure that the system maintains an isolation barrier between the networks. So, that one generic Linux system is "visable" to each network, with it's own unique address /on each network/.
The trick, with the RPi, is to be able to physically connect it to both networks.
1) On some RPIs, you could hardwire one network to the RPI ethernet port, and use the built-in wifi to connect to the other network, or
2) hardwire one network to the RPI ethernet port and use a USB-WIFI dongle to connect to the other network, or
3) hardwire one network to the RPI ethernet port and use a USB-ethernet dongle to connect to the other network, or
4) hardwire /both/ networks to the RPI ethernet port (this would require running both networks through a switch, or a router configured as a "pass-through". (Note that a switch would maintain the independance and isolation of each network, while allowing both networks to use a shared cabling infrastructure).
So, my suggestion a) install a switch and connect it to both networks b) connect your RPI to the switch c) configure your RPI as a "host" (no routing between interfaces) d) configure your RPI ethernet with two "alias" interfaces a) give one alias interface an address on the /first/ network, b) give the other alias interface an address on the /second/ network. e) set up whatever drop-box software you need on the RPI (SAMBA, NFS, ftp, whatever).
Either you are describing that as something special when every other 'puter does the same, or you have read something I've never said.
But to make it absolutily clear, in my explanation the RPi is *passive*. It waits for connections initiated by both hosts, and only than tries to / can write received packets to the other interface.
Nope. Both sides can send and both sides can receive. The only thing that happens in the RPi is that the connection gets scrubbed (notice: the connection, not its data).
As in the above, it is supposed to be.
....
Why is it that "passive" also must mean "time delay" and (thus?) "files" ? I don't get it.
as well as for its multi-port usage ofcourse, which doesn't work well with (simple) firewalls.
But as mentioned, I had something /much/ simpler in mind - with the RPi being next to invisible.
Doesn't mean that I cannot also think of setting the RPi up as a multi-subnet data-storage device ofcourse. Heck, I might even think of setting up both !
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.
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Reading through this thread it seems you're worried that adding a USB ethernet dongle would slow traffic down. The built-in ethernet on the Pi hangs off the USB bus; adding another dongle uses the same USB bus. So, no extra slowdown. Two ethernet ports would normally be on two separate LAN segments, with (on Linux anyway) no connection between them unless forwarding is enabled - not by default.
Then look at NFS (network file system). Add nfs-kernel-server to your Pi. Both Windows and Linux have NFS clients.
You can then export a single directory which can be mounted by clients. Each client can then read and write (if set up like that) to that directory as if it were a local directory. e.g. in /etc/exports (/var/ftp/pub is on the Pi) (see also below) this exports a public directory /var/public 192.168.0.0/24(rw,sync) 192.168.100.0(rw,sync)
e.g. raspberrypi:/var/public /home/rudy/raspberry nfs rsize=8192,wsize=8192 0 0
Options can be found in man nfs.
from man exports: EXAMPLE # sample /etc/exports file / master(rw) trusty(rw,no_root_squash) /projects proj*.local.domain(rw) /usr *.local.domain(ro) @trusted(rw) /home/joe pc001(rw,all_squash,anonuid=150,anongid=100) /pub *(ro,insecure,all_squash) /srv/www -sync,rw server @trusted @external(ro) /foo 2001:db8:9:e54::/64(rw) 192.0.2.0/24(rw) /build buildhost[0-9].local.domain(rw)
The first line exports the entire filesystem to machines master and trusty. In addition to write access, all uid squashing is turned off for host trusty. The second and third entry show examples for wildcard hostnames and net? groups (this is the entry `@trusted'). The fourth line shows the entry for the PC/NFS client discussed above. Line 5 exports the public FTP directory to every host in the world, executing all requests under the nobody account. The insecure option in this entry also allows clients with NFS implementations that don't use a reserved port for NFS. The sixth line exports a directory read-write to the machine 'server' as well as the `@trusted' netgroup, and read-only to netgroup `@external', all three mounts with the `sync' option enabled. The seventh line exports a directory to both an IPv6 and an IPv4 subnet. The eighth line demonstrates a character class wildcard match.
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.
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
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
Ethernet is the same ever since co-ax died, it's all point-to-point we just call the (rather specialised) computer with a lot of ports a switch.
It runs in the switches these days but it is still there.
Indeed it does - but multi-drop interfaces are mostly out of fashion these days (apart from open air ones of course).
--
Steve O'Hara-Smith | Directable Mirror Arrays
C:\>WIN | A better way to focus the sun
The computer obeys and wins. | licences available see
You lose and Bill collects. | http://www.sohara.org/
I think you, R. Wieser, are using "passive" as a reference to which host /initiates/ the connection.
Where as some people in this thread have taken "active" vs "passive" to mean "doing something with the traffic to copy it from one interface to another".
Traditionally, in both computers and electronics, a passive device is one that will function without any power, conversely an active device will not function without power.
A DB-25 to RJ-45 adapter is passive in that it's wires and unpowered. Conversely, a Pi is an active device that will not function without power.
So, we get into the minutia of /what/ /specifically/ the Pi is doing and if it constitutes active or passive.
I think that many would support that routers, particularly routers that alter traffic as it passes through, are /active/ devices.
You have stated that you want to /actively/ decide what traffic to allow through or not.
You have also stated that you want software to read from one interface and write to another interface. Both of those are active functions.
Even if you don't consider traditional routing to be active, you have indicated that you are considering writing a custom program to read from one interface and write to another, possibly via sockets with the existing TCP/IP stack. This sounds very active to me.
The Pi can be both active in that it processes traffic and /reactive/ in that it only does so in response to external stimuli.
So, please clarify what you mean by "active" vs "passive" as well as "initiator" and "responder". Please also re-state your desires while clearly indicating what is active / passive and initiator / responder.
The "scrubbing" supports some sort of active process on the connection.
Connection vs data is getting into the minutia and we need to share a common understanding of what each other means. Lest we talk in circles around each other.
Unless or until corrected, I'm going to take "passive" to mean "does not initiate / responds to external initiation".
In typical file drop / post office scenarios, the recipient can't /safely/ read the file until /after/ the file is completely written. As such, you are introducing a delay of some amount of time.
Conversely, an active process can read from one socket and write to another socket in almost parallel. (There is a tiny but measurable delay.) It can certainly start writing to the second socket before the data is finished being written to the first socket.
If by "simple" you mean "stateless", sure.
I'm not convinced that the Pi will be as invisible as I think you are thinking.
Hosts A and C will know the remote IP that they are talking to. They can share that information in the data that passes between them (much like FTP does) and can detect that each other are not at the addresses they are talking to.
Does this visibility matter? Probably not. But it might.
"normally" is the /operative/ word. FTP and SIP are two off the cuff examples of protocols that /do/ care /greatly/.
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.
Thanks. I already got that idea too, but as I know almost nothing about the possibilities ...
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.
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.
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.
:-) I'm quite aware of that.
Not quite. As I said, the port information is dropped too. Always.
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.
Ah, I misunderstood what it might do.
Yes, I'm aware of that. The whole idea is that I /want/ them to communicate - but only on my conditions.
I understood that. It was just to make a point as to how far I would go to keep everything apart.
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.
So, all of those 'puters are than electrically connected ? In that case, how does that stop a 'puter from one "subnet" to try to talk to a 'puter of another "subnet" ? It just needs to stop or bypass its default gateway, and away it goes !
Which is pretty-much exactly why I maintain an electrical seperation for my subnets.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.