xarek1986
@xarek1986
Инженер

Как дать доступ в интернет через промежуточную сеть?

Доброго дня!
Имеем:
1. Linux server с двумя интерфейсами:
eth0 - ip public смотрит в интернет masquerade
eth1 - ip 172.16.18.1 смотрит в локальную сеть

2. Микротик с двумя интерфейсами:
fa1 - ip 172.16.18.5 смотрит на сервер
fa2 - ip 172.16.4.1 смотрит во вторую локальную сеть
firewall всё разрешает

3. Клиенты с адресами из 172.16.4.0/24 и шлюзом по умолчанию 172.16.4.1

Задача: пустить клиентов к определённым выделенным IP, например 93.158.134.3 (yandex) в интернете через первый сервер.
Что уже есть:
На клиенте:
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


На маршрутизаторе:
/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


На сервере:
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:

в итоге получаем, что с микротика yandex доступен через первый сервер
а с клиента, пакеты застревают на интерфейсе eth1 (локальный) сервера
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


Уже неделю бъюсь над этой задачей, и не могу понят, в чём проблемма.
Знаю, что есть подобное про VPN, но видимо народ пугается, при виде незнакомых продуктов, по этому решил описать на простом примере
  • Вопрос задан
  • 430 просмотров
Решения вопроса 1
xarek1986
@xarek1986 Автор вопроса
Инженер
Проблема оказалась в FirewallD. В виду специфики его работы (или моей криворукости) доступ к внешнему интерфейсу был разрешён только из сети 172.16.18.0/24 о чём свидетействовало правило
-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


При этом, если попробовать добавить 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

то они не отрабатывали (почему-то).
Заработало только после ручного вмешательства, что не очень хорошо, хотя и пока не критично
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

В общем, благодаря неоценимому вкладу Александр Карабанов нам удалось понять в чём проблемма.
для себя я написал скрипт, где прописываются нужные роуты и добавляются вышеописаные правила
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
@smartchecker
Зачем в данной схеме mikrotik?
На мой взгляд - это лишняя сущность.
По делу:
На linux'е пользуйтесь iproute2
ip a
ip r
ip l
и т.д.
Статический роутинг - зло!
У роутера может быть только один статик на gw провайдера, всё остальное - динамика.
На микротике не NAT'им трафик из сети 172.16.4.0/24 к требуемым внешним ip.
На линухе его ловим и NAT'им.
Ответ написан
Не может ли быть ошибки в настройках NAT для сети 172.16.4.0/24 на Linux-сервере ?
И попробуйте для контроля "картинки" пинг до Яндекса с Микротика но с внутреннего интерфейса SRC_IP=172.16.4.1 ?
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы