How to give access to the Internet through an intermediate network?

Question

linux

Good day!
We have:
1. Linux server with two interfaces:
eth0 - ip public looks at the Internet masquerade
eth1 - ip 172.16.18.1 looks at the local network
2. Mikrotik with two interfaces:
fa1 - ip 172.16.18.5 looks at the server
fa2 - ip 172.16.4.1 looks into the second local network
firewall allows everything
3. Clients with addresses from 172.16.4.0/24 and a default gateway 172.16.4.1
Task: let clients access certain dedicated IPs, for example 93.158.134.3 (yandex) on the Internet through the first server.
What is already there:
On the client:

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.4.1      0.0.0.0         UG    100    0        0 enp2s0
172.16.4.0      0.0.0.0         255.255.255.0   U     100    0        0 enp2s0

On the router:

/ip route prin
Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, b - bgp, o - ospf, m - mme, B - blackhole, U - unreachable, P - prohibit 
 #      DST-ADDRESS        PREF-SRC        GATEWAY            DISTANCE
0 ADC  172.16.18.0/24     172.16.18.5     fa1                       0
1 A S  193.239.202.174/32                 172.16.18.1               1
2 ADC  172.16.4.0/24      172.16.4.1      fa2                      0

On server:

route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         public_gw    0.0.0.0         UG    100    0        0 eth0
public_net    0.0.0.0         255.255.255.248 U     100    0        0 eth0
172.16.4.0      172.16.18.5     255.255.255.0   UG    0      0        0 eth1
172.16.18.0     0.0.0.0         255.255.255.0   U     0      0        0 eth1

firewall-cmd --list-all --zone=internal
internal (default, active)
  interfaces: eth1
  sources: 172.16.18.0/24 172.16.4.0/24
  services: dhcpv6-client http https ipp-client mdns mountd nfs rpc-bind samba-client ssh
  ports: 
  masquerade: no
  forward-ports: 
  icmp-blocks: timestamp-reply timestamp-request
  rich rules:

firewall-cmd --list-all --zone=external
external (active)
  interfaces: eth0
  sources: 
  services: http https ssh
  ports: 
  masquerade: yes
  forward-ports: 
  icmp-blocks: timestamp-reply timestamp-request
  rich rules:

as a result, we get that from mikrotik yandex is available through the first server
and from the client, the packets get stuck on the eth1 interface (local) of the server

tracepath -n 193.239.202.174
 1?: [LOCALHOST]                                         pmtu 1500
 1:  172.16.4.1                                            0.672ms 
 1:  172.16.4.1                                            0.629ms 
 2:  172.16.18.1                                         140.151ms 
 3:  172.16.18.1                                         138.824ms reached
     Resume: pmtu 1500 hops 3 back 2

I've been struggling with this task for a week now, and I can't figure out what the problem is.
I know that there is something similar about VPN, but apparently people get scared when they see unfamiliar products, so I decided to describe it with a simple example

Answer 1

The problem turned out to be FirewallD. In view of the specifics of its work (or my curvature), access to the external interface was allowed only from the network 172.16.18.0/24, as evidenced by the rule

-A FORWARD -d 172.16.18.0/24 -i eth0 -o eth1 -j ACCEPT
-A FORWARD -s 172.16.18.0/24 -i eth1 -o eth0 -j ACCEPT

At the same time, if you try to add direct-rule

ipv4 filter FORWARD 0 -i eth0 -o eth1 -d 172.16.4.0/24 -j ACCEPT
ipv4 filter FORWARD 0 -i eth1 -o eth0 -s 172.16.4.0/24 -j ACCEPT

then they did not work out (for some reason).
It worked only after manual intervention, which is not very good, although not yet critical

iptables -I FORWARD 1 -d 172.16.4.0/24 -i eth0 -o eth1 -j ACCEPT
iptables -I FORWARD 1 -s 172.16.4.0/24 -o eth0 -i eth1 -j ACCEPT

In general, thanks to the invaluable contribution of Alexander Karabanov , we managed to understand what the problem is.
for myself, I wrote a script where the necessary routes are prescribed and the above rules are added

Answer 2

Why is mikrotik in this scheme?
In my opinion, this is a redundant entity.
Case in point:
On linux, use iproute2
ip a
ip r
ip l
etc.
Static routing is evil!
A router can have only one static per gw provider, everything else is dynamic.
On Mikrotik not NAT'im traffic from the network 172.16.4.0/24 to the required external ip.
On linux we catch it and NAT'im.

Answer 3

Could there be an error in the NAT settings for the 172.16.4.0/24 network on the Linux server?
And try to control the "picture" ping to Yandex from Mikrotik but from the internal interface SRC_IP=172.16.4.1 ?