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

On 28/06/2020 15:45, Alister wrote:


Ding! Ding! Ding! We have a winner.


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

On Fri, 26 Jun 2020 19:24:10 +0200



    Thought so. In that case you need to add a second ethernet to the
Pi - a good USB-2 ethernet should get you 100Mb/s, connect one to each of
the networks and arrange for NFS or Samba to export shares to both networks.

On 26.6.20 21:39, Ahem A Rivet's Shot wrote:



The OP stubbornly refuses to get and set up the hardware
which would do what he wants. Both a second USB-Ethernet
adapter or a VLAN switch will do the separation.

Using a serial line for tunneling Ethernet fraemes is
more challenging, but doable. I have experience, had
to do it due to power limitations. An Ethernet interface
needs more power than we could feed to a device for
exlopsion-proof environment (ExI).

Tauno Voipio wrote:


Always. Please killfile.

Ahem,



:-) Which is what my initial question started with.   Should I just plug a  
ethernet dongle into an USB port, or are other (and perhaps better) options  
available ?

Second, how do handle (configure) such an extra interface ? Especially as I  
do not want either interface to be able to talk to the other without my  
say-so.

Are there (open source, sourcecode) programs available which will handle  
such (very restriced) communication ?

As I said, I'm a rather newbie in regard to both Linux as well as the RPi.  
I could do worse than to work my way thru a tutorial or get my (rather  
needed) pointers from someone elses project.



:-)  Although I know of the latter by way of what Windows offers (SMB), I  
have no idea what exactly the SAMBA service does or how I should/need to  
configure it.   Let alone which things I all need to disable to be sure no  
inadverted connections can be made between the interfaces.

Last, but certainly not least, I have no problem with trying to whip up  
something myself.  In fact, that is pretty-much where my hobby lies.

Regards,
Rudy Wieser

On Sun, 28 Jun 2020 11:54:16 +0200



    The only other real option is VLANs and a smart switch - USB
ethernet is simpler.



    That depends - if both networks have DHCP servers then just
configure the new interface to use DHCP (probably default), plug it in and
watch it connect.



    You would have to do extra work to get packets passed between them.



    Once you have them both connected you can run services listening to
either or both. You could set up samba with a share visible to both
read/write and use it like a drop box, or you could set up an ftp server,



    This is pretty much off-the-shelf. In your position I'd probably go
with samba and set up a share or two.



    Samba is an open source SMB server, there's a vast amount available
on configuring it.

    You don't need to disable anything, you would need to enable
routing for there to be connections between the interfaces.

Ahem,



I was thinking more in the direction of a a "hat" plugged onto the RPi's I/O  
connector, but I get the message.



That sounds easy enough.

Part of my problem is that I have no idea what the RPi OS does when it sees  
two network interfaces.   Under Windows it would blabber all kinds of  
(discovery) broadcasts and data over both - which is not what I want to have  
happen.



Which would be falling right into the target-zone of my programming hobby.  
:-)



Yeah, I know.



That sounds good.

Perhaps even good enough to continue in this direction ...

Regards,
Rudy Wieser

On Sun, 28 Jun 2020 16:51:47 +0200



    It *should* be that easy - worst case you have to add a config file
for the USB ethernet.



    If DHCP is enabled on the interface (almost certainly) then it will
broadcast a DHCP discover and listen for an offer, once all that has
settled down and it has an IP address it will settle back and listen on it
with any active services (probably only ssh) that haven't been configured
not to (every service I can think of can be configured to listen on a
specific address and/or interface so you can arrange for it to provide
selected services to one network and not the other if you want).



    It's not much work - set a flag on the Pi and tell the two subnets
that they can find each other via the Pi. Until you do that the Pi is the
only thing that can see and be seen on both subnets.



    I think you'll find it the path of least resistance, and the path
that offers maximum future possibilities.

Ahem,



You are quite light on information, but I'm already quite sure that that is  
*not* what I want to have happening.



I think I will keep it that way.

Regards,
Rudy Wieser

On June 28, 2020 15:00, R.Wieser wrote:



Effectively, that makes the RPi a router.



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

f) there is no "f"

HTH

Lew,



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.

Thanks for the suggestion though.

Regards,
Rudy Wieser

On June 28, 2020 17:45, R.Wieser wrote:



Nominally, your (secured) configuration on each system would ensure that  
systems neither add themselves to the other subnet nor modify the existing  
routing that keeps each subnet logically isolated.



Implying that your system configurations aren't very secure, I guess.



C'est la vie. It was a suggestion, nothing more.

Regards

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

On Sun, 28 Jun 2020 21:00:16 +0200



    So am I, which is why I was light on detail.

On 6/28/20 7:45 AM, Ahem A Rivet's Shot wrote:


It's possible to do this on a single Ethernet connection.  It just takes  
more knowledge and a little more work.

It's entirely possible to rely on /protocol/ isolation to do what the OP  
wants on a /sing.e/ common network.

Hosts A and B can communicate with each other over IPv4 and hosts B and  
C can communicate with each other over IPv6.  If host A has zero IPv6  
support and host C has IPv4 completely disabled, there is no way for  
hosts A and C to talk directly to each other.

It's even possible to do this with IPv4.  Configure completely different  
subnets.  Configure firewalling so that hosts A and C block any and all  
traffic from each other.  Or better, configure hosts A and C so that  
they only allow traffic from B.

This filtering could be IP and / or MAC based.  I think MAC based would  
be simpler and more robust.

There are many ways to do what the OP wants to do on a single Ethernet  
interface.

PPPoE, MPLS, etc are options too.



Your suggestions are correct for many environments.  However I suspect  
that the OP's environment is decidedly different.  If the OP has three  
devices, hosts A, B, and C cabled together (in a daisy chain), chances  
are quite good that there won't be a DHCP server.



Linux (and most other OSs) simply need a setting changed.  It's not as  
if the OP needs to do something to allow each and every connection.



I sort of suspect that the OP might prefer an (S)FTP(S) server over  
Samba.  Both Samba and NFS (NAS protocols) can easily have their files  
modified (presuming the user has permission) with non-network-aware  
scripts / programs.  Conversely, (S)FTP(S) is typically not a mounted  
file system.  As such, there is an access barrier that makes things a  
little safer than NAS protocols.

Something a simple as an rm that has gone awry can't effect things on  
(S)FTP(S) the same way that it can a mounted NAS file system.



If I were going to do a NAS protocol, I'd use the one that is native to  
the platform.  Seeing as how the Raspberry Pi is Linux (at least what  
we've discussed thus far) I'm going to suggest that NFS be used.

Samba in particular has some down sides compared to NFS related to how  
the ""server sees the connections.  NFS inherently supports multiple  
users over the same connection.  Samba does not do so nearly as cleanly.  
  This may not matter in this situation.



The Linux kernel doesn't forward packets by default.  But some Linux  
distributions do enable forwarding by default.

He would also need to add routes to A & C so that they would know to get  
to each other via B.

On Sun, 28 Jun 2020 10:45:51 -0600



    It also entails more risk.



    Yes it is - but it is even more fragile from a security perspective
than VLANs.



    Apart from promiscuous mode and/or packet injection.



    One glitch in the firewall rules and it all falls open.



    The OP explicitly mentions two subnets - so that doesn't fit.



    That is indeed the extra work - my point is that it won't just
happen.



    That is of course an option and there are many more.



    Ouch nasty I've not seen that except on builds meant for routers,
and not on anything common on a Pi.



    For everyone but the hackers yes.

On 6/28/20 11:39 AM, Ahem A Rivet's Shot wrote:


Yes, a single Ethernet NIC is more risky than multiple Ethernet NICs.  
But there are ways to mitigate it with belt and suspender redundancy.  
Depending on the OP's neeed, the simplicity and minimal additional risk  
might be acceptable.



I don't completely agree.

It's trivial to have a kernel without IPv6 support.  It's slightly more  
complicated to have a kernel without IPv4 support.  (At least the last I  
looked.)

I think that 802.1Q VLAN tagging is great.  I've done a LOT with it in  
my career.  But there are ways around it.



One extremely important thing is do you trust the A & C endpoints?  Or  
are you considering them to be hostile and defending against them.  The  
latter requires completely different, and likely more complex, solutions  
than the former.



Not necessarily.

You can put the firewall rules on both systems.
You can add static ARP entries.
You can put the systems in separate subnets without a route.

Yes, all of these things can be overcome.  But that goes back to the  
question of trusting A & C.



The existence of a DHCP server (or not) is independent of subnets.

Besides, what I'm describing would be two different subnets.

  |-----|          Cable 1 / Subnet A
[A]---[B]---[C]   Hosts A / B / C
        |-----|    Cable 2 / Subnet B



(See comment's below.)



Yep.

It is highly dependent on what the OP is wanting to do.



But it is decidedly a possibility where the OP can end up with the  
system routing traffic without doing any additional action.  ;-)



Trust of the devices is extremely important.

Even if there is a hacker on A, C will have to have a route to get back  
to A.  The hacker can't always do it without some support on the other  
end for bidirectional communications.

I get the impression that the OP is in control of all three systems, and  
as such, probably trusts them about the same.

On 6/28/20 3:54 AM, R.Wieser wrote:


There are a number of options.  Some are more practical than others.



Adding an additional network interface to a Linux machine is fairly  
easy.  Configuring said Linux machine to not forward traffic between the  
two interfaces is also relatively easy.  (Linux itself defaults to /not/  
forwarding.  But some distributions change that.)



That makes me think that you want hosts A and C to communicate with each  
other across some routed network.  This differs from my previous  
understanding of what I thought you wanted.  I thought you /explicitly/  
wanted hosts A and C to NOT be able to talk to each other at all.  
Further, that any ""communications (read: exchange of files / etc.)  
would be done but putting files in a common location, B.



Welcome.

If anything, Linux, and the Raspberry Pi suffer from too many options.



Typically, in scenarios like the one you're asking about, it's okay if  
the services listen on multiple interfaces on B.  The purpose is to  
prevent A and C from being able to talk to each other directly.  So, A  
talking to B on the AB interface is fine, as is C talking to B on the BC  
interface.  There usually is no harm in something like Samba listening  
on multiple interfaces.  Presuming you are using the same protocol on A  
and C, in some ways having Samba (et al.) on B listen on multiple  
interfaces is required.



:-)

Learning opportunities are good.  But you may want to avoid painting  
yourself into a corner and making things harder on yourself than is  
strictly necessary.  Why re-create programs if you can use existing  
programs.  Especially if said existing programs will happily work with  
the isolation that you desire.

Grant,



:-)   Now I still know nothing.

The thing is I know very few options, and I named both ("hat" and dongle).  
However, I do know that using an USB dongle will throttle the speed to that  
of the USB port.  I have no idea if any of the other possibilities will do  
better.



No, no intermediate network.    The hosts are always in the same room.



I did, and stil do.  But I also said /directly/.

Instead of an UUCP program dropping a file somewhere where the other side  
can read it I was thinking of a program which reads a data paccket from one  
interface and that writes to the other - in the process dropping all headers  
(containing the MAC, IP, port) in either direction (replaced by ones from  
the RPi).  It would be real-time communication, but definitily not directly.

Hmmmm... Does that UUCP program allow one interface to write a file while  
the other interface is reading from it at the same time ?   That would be  
comparable.



True.  As long as that process does not inadvertedly creates some kind of an  
U-turn allowing data to pass from one interface to the other (allowing a  
direct A-to-C communication).     Yeah I know, that sounds a bit paranoid,  
but its better to make sure that that can't happen than (much) later pay the  
price for it.



Agreed.  But I would not have any qualms to install SAMBA twice, once for  
each interface, only coming together on the file-storage level.



The former doesn't automatically follow from the latter.



Why else ?    Because I want to see if I can do it myself. :-)    Its also a  
good(?) way to get to know the OS a bit under its surface. Besides, if that  
fails I can always fall back on stuff that others wrote.



They won't. But as I have quite a bit of experience with programming and  
TCP/IP on a Windows machine I don't think that writing a program for it*  
will give me much trouble.

*simple file-transfer first, maybe automatic clipboard exchange later.

Regards,
Rudy Wieser

On 6/28/20 11:48 AM, R.Wieser wrote:


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.