[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: sharing a network connection from debian to non-debian



On 1/19/2021 1:40 AM, Dan Hitt wrote:
On Sun, Jan 17, 2021 at 11:41 PM David Christensen <
dpchrist@holgerdanske.com> wrote:

On 2021-01-16 10:28, Dan Hitt wrote:

I probably never made my situation very clear, but i do now have a
solution.  I'm posting it here for the benefit of anybody who has a similar
problem, and finds this thread.

First, the setup is that i have 3 hosts:
A  --- runs debian 10
B  --- runs linux mint 16.04
C  --- old hardware which cannot connect to my internet-modem-router.

Each of the 3 hosts has 2 network interfaces; there are thus 3 LANs (local
area networks), and each host is on two of them, but not the third.

The internet-modem-router is on the same LAN as A and B, because C cannot
connect to it directly without destabilizing or sometimes just locking.

I installed linux mint 16.04 on host B about 5 years ago.  Setting up the
network was easy: all i had to do was select some option in some gui that
said "shared" or "share network" or something like that.  That just worked,
and host C could see the internet through host B.  It still does work, by
the way.

However, i would like to upgrade host B to use debian 10, just like host A.

When i do that, host C will lose (or would have lost) connectivity to the
internet because host A did not share its internet with host C.

So, before upgrading host B to debian, it was necessary to get the network
working properly on the LAN connecting A and C.  This, by the way, can be
tested on C by using the -S argument with ping.  On host C, i can run "ping
-S X.Y.Z.W google.com".  By setting X.Y.Z.W to the ip of the BC interface,
it will go through B (mint), and it does that successfully.  But by setting
X.Y.Z.W to the ip of the AC interface, it would have to go through A
(debian), and until i fixed it (as described below), this would fail.

So although i agree that in general, it makes sense to upgrade to a clean
host before trying to get the network running, in this particular case it
was imperative to first get the network running through a host, A, that was
already in existence and has a couple of years' usage, before upgrading
host B (currently mint, but hopefully soon to be debian).

The one advantage of this setup though, is that it was possible to compare
a working system (B, mint) with a non-working system (A, debian).

I ran across this article by Nico Brailovsky,
https://monoinfinito.wordpress.com/series/setting-up-a-linux-gatewayrouter-a-guide-for-non-network-admins/
which explained how to do it.

First, one must adjust /proc/sys/net/ipv4/ip_forwarding.

On host B (mint), the working system, that file had an ascii '1' in it.  On
host A (debian), the non-working system, that file had a '0' in it.  So i
changed it on A, to be '1'.

Then, the ip tables have to be updated.

The commands Brailovsky gave need to be modified just slightly, due to
differences in naming conventions of the interfaces.

They are:
  sudo iptables --table nat --append POSTROUTING --out-interface enp2s0 -j
MASQUERADE
and then
sudo iptables --append FORWARD --in-interface XXXXXXXXX -j ACCEPT


Note that Debian is moving from Iptables to Nftables, the effect of the
above cmds will be lost when rebooting the host.



Here, enp2s0 is the standard name for the motherboard ethernet port, and
XXXXXX is to be replaced by the name of the second interface.  In my case,
it is etherhet-over-usb, so is some long name that would be different for
every host.

And that's it.  I didn't even have to restart the networking service ---
although i did restart it after editing /proc/sys/net/ipv4/ip_forwarding,
just to see if changing that one file would be enough to get things
working.  (Just for reference, restarting the networking is done by 'sudo
/etc/init.d/networking restart' . )


On Debian you would probably want to use 'systemctl restart networking'
instead of calling the script directly.
Restarting the networking service is not required when you
enable/disable ipforwarding.

Using a frontend to IP/Nftables might be worth considering.

--
John Doe


Reply to: