On 6/28/20 11:48 AM, R.Wieser wrote:
> :-)   Now I still know nothing.

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.

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

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.

> No, no intermediate network.

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.

> The hosts are always in the same room.

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.

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

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.

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

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.

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

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.

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

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.

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

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.

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

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.

> The former doesn't automatically follow from the latter.

Agreed.

> Why else ?

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

> Because I want to see if I can do it myself. :-)

I honestly don't need anything stronger than that.

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

True.

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

Fair enough.

I was thinking industry standard news and email servers & clients on
each end exchanging files through the intermediary.

> *simple file-transfer first,

There are a lot of ways to solve this problem.

> maybe automatic clipboard exchange later.

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.



--
Grant. . . .
unix || die

--- SoupGate-Win32 v1.05