On Mon 28/Jun/2021 09:46:50 +0200 Reindl Harald wrote:
Am 28.06.21 um 09:32 schrieb Alessandro Vesely:
On Sat 26/Jun/2021 12:43:45 +0200 Reindl Harald wrote:
/usr/sbin/ipset -file /etc/sysconfig/ipset restore
/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
/usr/sbin/sysctl -q --load=/etc/sysctl*.conf
that way first all rules are loaded atomic and *then* "ip_forward" and
friends are set to avoid a leak at boot
it may be good for you pro administrators with complex configurations...I
have all in one file and do not need to bother about 1ms lost during reload
nor seeking 10 different config files for simple tasks and wasting hours by
config. I like easy life.
mixing things together which don't belong together like iptables and sysctl
is the opposite of simple as well as running a ton of commands at boot where
it should be a oneliner is also the opposite
I'm with David here. Besides sysctl and ipset, there are lots of ip
commands, modprobe's, vconfig, and a couple of home-brewed daemons (ipqbdb).
A soundly commented script captures the logic of the network and can be
maintained with more coherence than raw commands accumulated along the way.
The only drawback is that most changes, for example punching a hole in the
firewall, have to be applied twice, in the boot script as well as directly in
a terminal.
and what does this different at boot besides that it's faster and atomic
compared to a complex and error prone script?
/usr/sbin/ipset -file /etc/sysconfig/ipset restore
/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
/usr/sbin/sysctl -q --load=/etc/sysctl*.conf
A complex script doesn't have to be error prone.
Speed is not a concern, given that boot only happens once every few months.
Setting iptables atomically is not needed because ip link set $interface up commands are issued after iptables -A ones.
guess what - i maintain network configs with a single systemd-unit but that
don't justify not using "restore" commands when they exist and are appropriate
for the task
-------------
[root@testserver:~]$ cat /etc/systemd/system/network-up.service
That's similar to what I do, except for restoring iptables. As I don't use systemd, my main script is a shell script in /etc/init.d/. I paste a few snippets from it.
# Firewall-Regeln laden
ExecStart=/usr/sbin/ipset -file /etc/sysconfig/ipset restore
ExecStart=/usr/sbin/iptables-nft-restore /etc/sysconfig/iptables
ExecStart=/usr/sbin/ip6tables-nft-restore /etc/sysconfig/ip6tables
# LAN-Interface konfiguieren
ExecStart=-/usr/sbin/ip addr add 192.168.196.12/255.255.255.0 broadcast 192.168.196.255 dev lan
ExecStart=-/usr/sbin/ip link set dev lan up
Similar at mine, except as noted. My script starts by setting numbers, like so:
# Network setup.
# Using this is more direct and precise than ifup/ifdown, since
# all IPs are static. (However, still missing a failover strategy)
#
# interfaces names, eth{0,1,2,3,4}r are defined in /etc/udev/rules.d/70-persistent-net.rules
fastweb_base=192.168.4
fastweb_if=eth0r
fastweb_bits=24
fastweb_ip=$fastweb_base.1
fastweb_cidr=$fastweb_ip/$fastweb_bits
fastweb_peer=$fastweb_base.254
fastweb_net=$fastweb_base.0/$fastweb_bits
# set fastweb_tracehost
fastweb_tracehost="93.63.100.61"
eutelia_base=62.94.243
eutelia_bits=28
#eutelia_bits=30
eutelia_ip=$eutelia_base.226
eutelia_cidr=$eutelia_ip/$eutelia_bits
# Sun 04 Nov 2018: 225 = Destination Host Unreachable
# eutelia_peer=$eutelia_base.225
eutelia_peer=62.94.107.161
eutelia_net=$eutelia_base.224/$eutelia_bits
# setting eutelia=eth3r (leftmost), interna = eth2r (rightmost)
# vlan
eutelia_if_raw=eth3r
eutelia_if=${eutelia_if_raw}.2
I left old values commented out, rather than deleting them. I try and use the same names for shell variables, names in rt_tables and iptables. Device names differ. I annotate these cross referencing in comments.
That way, I can then use shell variables in iptables commands as in the next snippet below. How do you handle renumbering otherwise?
#########################
# for policy checking, matrix subdivision is used to gather
# packets into four chains: external and internal _in, and the
# two forwarding directions (interna2externa, externa2interna)
# first matrix subdivision
iptables -A INPUT -i $interna_if -j interna_in
iptables -A INPUT -i $eutelia_if -j eutelia_in
iptables -A INPUT -i $fastweb_if -j fastweb_in
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -i tun0 -j externa_in
iptables -A FORWARD -i $interna_if -o $fastweb_if -j interna2externa
iptables -A FORWARD -i $interna_if -o $eutelia_if -j interna2externa
iptables -A FORWARD -i $eutelia_if -o $interna_if -j eutelia2interna
iptables -A FORWARD -i $fastweb_if -o $interna_if -j fastweb2interna
And eventually:
# interfaces
ip addr add $fastweb_cidr dev $fastweb_if broadcast + scope global
ip link set $fastweb_if up
# Sun 04 Nov 2018: Setting up the raw device as well...
ip addr add $eutelia_cidr dev $eutelia_if broadcast + scope global
ip link set $eutelia_if_raw up
ip link set $eutelia_if up
# NIC-Konfiguration
ExecStart=-/usr/sbin/ethtool -G lan rx 512 tx 256
ExecStart=-/usr/sbin/ethtool -K lan lro off
ExecStart=-/usr/sbin/ethtool -G wan rx 512 tx 256
ExecStart=-/usr/sbin/ethtool -K wan lro off
I hadn't had to do that, yet (been lucky with autoconf?)
# Routing von VPN/Host-Netzwerken
ExecStart=-/usr/sbin/ip route add 10.0.0.0/24 via 192.168.196.2 dev lan
ExecStart=-/usr/sbin/ip route add 172.17.0.0/24 via 192.168.196.2 dev lan
ExecStart=-/usr/sbin/ip route add 192.168.11.0/24 via 192.168.196.2 dev lan
# Sicherstellen dass 'sysctl' angewendet wird
ExecStart=-/usr/sbin/sysctl -q --load=/etc/sysctl*.conf
Shouldn't this be automatic?
[root@testserver:~]$ cat /etc/systemd/system/network-wan-dhcp.service
[Unit]
Description=Internet DHCP-Client
I set up DHCP independently of the network. It only listens to the internal interface, so it's somewhat easier. I consider it a separate issue.
Best
Ale
--
