Главной трудностью этой задачи является то, что хост, на который пробрасывается порт, должен знать, через какой шлюз отправлять ответ для установки соединения. Если этого не сделать, то ответ пойдет через маршрут по умолчанию и соединение не установится. Можно это сделать с помощью "Policy Base Routing" промаркировав необходимые пакеты и завернув их через определенный шлюз. Или же с помощью "SNAT", но тогда мы лишимся информации о том, с какого адреса из Интернета пришли запросы. Будут показаны два способа. Это может понадобиться, когда, например, в главном офисе у нас статический белый ip-адрес, а в филиале серый или динамический, и нам нужно открыть ресурс в филиале через главный офис.
Схема сети:
В данном примере маршрутизация между сетями LAN уже настроена.
R2: - Client
- ISP: 2.2.2.2
- VPN Tunnel: 172.16.255.2/32
- LAN: 172.17.5.0/28
R1: - Server
- ISP: 1.1.1.1
- VPN Tunnel: 172.16.255.1/32
- LAN: 172.16.5.0/28
Хост где-то в Интернете, с внешним адресом 3.3.3.3.
[SYN] - Трафик с адреса 3.3.3.3 приходит на 1.1.1.1 (R1), NAT-ится(DNAT) в 172.17.5.4.
[SYN+ACK] - Хост 172.17.5.4 смотрит в таблицу маршрутизации и видит, что 3.3.3.3 в ней нет, смотрит маршрут по умолчанию - 0.0.0.0/0, он ведет через 2.2.2.2 в Интернет, далее шлет туда ответ. В результате, в лучшем случае ответный трафик приходит на 1.1.1.1 с публичного адреса 2.2.2.2 ( а должен с публичного адреса 1.1.1.1 пройдя через VPN Tunnel ). Итог: трафик отбрасывается файрволом на 1.1.1.1.
[ACK] - Подтверждение не отправлено. Соединение не устанавливается.
Policy Base Routing: Рекомендуемый способ.
Настройка с заворачиванием ответного трафика через правильный шлюз.
# Router R1:
- NAT:
/ip firewall nat add chain=dstnat in-interface=FTTx protocol=tcp dst-port=555 action=dst-nat to-addresses=172.17.5.4 to-ports=8000 comment="DNAT via VPN"
- Filter Rules:
/ip firewall filter add chain=forward in-interface=FTTx out-interface=<l2tp> action=accept comment="DNAT via VPN"
# Router R2:
- Filter Rules:
/ip firewall filter add chain=forward in-interface=u_255.2 out-interface=bridge1 dst-address=172.17.5.4 protocol=tcp dst-port=8000 action=accept comment="DNAT via VPN"
- Mangle Prerouting:
/ip firewall mangle add chain=prerouting in-interface=bridge1 src-address=172.17.5.4 dst-address=!172.17.5.0/27 protocol=tcp src-port=8000 action=mark-routing new-routing-mark=dnat_via_vpn comment="DNAT via VPN"
- Static Route PBR:
/ip route add dst-address=0.0.0.0/0 gateway=172.16.255.1 routing-mark=dnat_via_vpn comment="DNAT via VPN"
- Rules:
/ip route rule add routing-mark=dnat_via_vpn action=lookup-only-in-table table=dnat_via_vpn comment="DNAT via VPN"
- Проверка для Router R2 после Filter Rules:
/ip route add dst-address=3.3.3.3 gateway=172.16.255.1
SNAT: Костыль.
Сделав SNAT, мы подменили адрес 3.3.3.3 на локальный адрес, в результате запросы и ответы пошли по туннельному линку. Но на сервере, куда делается DNAT, мы лишились сведений о том, с какого адреса из Интернета пришли запросы.
- NAT:
/ip firewall nat add chain=dstnat in-interface=FTTx protocol=tcp dst-port=555 action=dst-nat to-addresses=172.17.5.4 to-ports=8000
/ip firewall nat add chain=srcnat out-interface=<l2tp> dst-address=172.17.5.4 protocol=tcp dst-port=8000 action=src-nat to-addresses=172.16.255.1
- Filter Rules:
/ip firewall filter add chain=forward in-interface=FTTx out-interface=<l2tp> action=accept comment="DNAT via VPN"
Чтобы в правилах не слетали после переподключения "<l2tp>" интерфейсы, необходимо воспользоваться привязкой VPN подключений к интерфейсам - "Server Binding".
