Full forward from/to IP over VPN/tunnel

[Chicho Mancho]

Привет,

 

Имам следният казус, който явно е над възможностите(знанията) ми - имам 2 embedded device-a които ползват специфичен порт за комуникация със света.

Тъй като имам само едно реално IP ми дойде мъдрата идея да се опитам да изпозвам IP/port от отдалечна локация където имам пълен контрол над мрежата.

На двете места ползвам Mikrotik рутери и имам вдигнат IP tunnel (ако е нужен).

За да е по сложно, до устройствата стига само 1 кабел (после обикновен суич), така че Miktorik-а ги вижда през един интерфейс - не може да се вкара целия интерфейс в bridge например.

Предварително благодаря, дори за времето прекарано в четене :)

[JohnTRIVOLTA]

Не можах да разбера коя мрежа, тази при теб зад микротика или тази зад другият микротик трябва да се рутира през тунела, но и двата варианта са постижими. Трябва да добавиш за целта нужната рутинг таблица с нужният път, сорс нат с изходен интерфейс тунела и сорс нат на адреса на тунела при рутера от където ще излиза трафика.

[Chicho Mancho]

Явно не съм разяснил както трябва.

Location 1:
external IP: 1.1.1.1
internal networks:  192.168.10.0/24, 192.168.11.0/24
IP Tunnel: 10.100.0.1

Location 2:
external ip: 2.2.2.2
internal networks:  192.168.100.0/24, 192.168.101.0/24, 192.168.150.0/24
IP Tunnel: 10.100.0.2
Embedded device 1 from DHCP (sharing same cable): 192.168.150.100 port 1234
Embedded device 2 from DHCP (sharing same cable): 192.168.150.101 port 1234

Current situation:
IP tunnel over internet - 1.1.1.1  <-> 2.2.2.2
ssh from 192.168.100.xx -> 192.168.11.xx - OK
ssh from 192.168.10.xx -> 192.168.101.xx - OK

Target:
Internet -> 2.2.2.2 port 1234 -> 192.168.150.100 port 1234
Internet -> 1.1.1.1 port 1234 -> 192.168.150.101 port 1234

[Самуил Арсов]

Да ти кажа честно и аз не мога да ти разбера въпроса, но ако той е как да имаш достъп от Интернет без тунел до двете устройства зад MikroTik рутера е:

/ip firewall nat
add action=dst-nat chain=dstnat dst-port=1234 in-interface=ether1 protocol=tcp to-addresses=192.168.150.100 to-ports=1234
add action=dst-nat chain=dstnat dst-port=1235 in-interface=ether1 protocol=tcp to-addresses=192.168.150.101 to-ports=1234

Незнам дали не е излизшно да кажа, че в случая ether1 е WAN интерфейса. Не е нужно портовете да са симетрични WAN и LAN.

Ако искаш да е с тунел, трябва да рутираш мрежите между тунела и няма нужда от пренасочване на портове.

[Chicho Mancho]

1 minute ago, samyil said:

Да ти кажа честно и аз не мога да ти разбера въпроса, но ако той е как да имаш достъп от Интернет без тунел до двете устройства зад MikroTik рутера е:

/ip firewall nat
add action=dst-nat chain=dstnat dst-port=1234 in-interface=ether1 protocol=tcp to-addresses=192.168.150.100 to-ports=1234
add action=dst-nat chain=dstnat dst-port=1235 in-interface=ether1 protocol=tcp to-addresses=192.168.150.101 to-ports=1234

Незнам дали не е излизшно да кажа, че в случая ether1 е WAN интерфейса. Не е нужно портовете да са симетрични WAN и LAN.

Ако искаш да е с тунел, трябва да рутираш мрежите между тунела и няма нужда от пренасочване на портове.

Привет, порт-а трябва да остане 1234, за това се налага да се ползва второ реално IP.

[Самуил Арсов]

Добре, тогава тунел: - Най лесния и поддържащ от всички операционни системи тунел е l2tp. Първо конфигурация на l2tp Рутера/Сървъра

/ip address
add address=192.168.100.0/24 interface=ether2

/interface l2tp-server server
set authentication=mschap2 default-profile=default enabled=yes

/ppp secret
add local-address=172.17.2.1 name=user1 password=pass1 remote-address=172.17.2.2
add local-address=172.17.2.1 name=user2 password=pass2 remote-address=172.17.2.3

И конфигурация на клиента като XX:XX:XX:XX е ип адреса на l2tp сървъра, като пак повтарям клиент може да е директно Windows или Linux. Тук хватката е, че рутираш мрежата 192.168.100.0/24 където са въпросните устройства през 172.17.2.1 което е адрес в тунела на сървъра. За да работи това обаче трябва да "натнеш" интерфейса l2tp-out1 с последното правило, в противен случай трябва да рутираш и от сървъра което е малко излишно в тази ситуация.

/interface l2tp-client
add connect-to=XX:XX:XX:XX disabled=no name=l2tp-out1 user=user1 password=pass1

/ip route
add dst-address=192.168.100.0/24 gateway=172.17.2.1

/ip firewall nat
add action=masquerade chain=srcnat out-interface=l2tp-out1

В този вариант не ти трябва пренасочване на портове, ще виждаш цялата мрежа 192.168.100.0/24 през тунела, като естествено можеш да имаш повече отдалечени потребители (user1, user2)

[Chicho Mancho]

1 hour ago, samyil said:

Добре, тогава тунел: - Най лесния и поддържащ от всички операционни системи тунел е l2tp. Първо конфигурация на l2tp Рутера/Сървъра

/ip address
add address=192.168.100.0/24 interface=ether2

/interface l2tp-server server
set authentication=mschap2 default-profile=default enabled=yes

/ppp secret
add local-address=172.17.2.1 name=user1 password=pass1 remote-address=172.17.2.2
add local-address=172.17.2.1 name=user2 password=pass2 remote-address=172.17.2.3

И конфигурация на клиента като XX:XX:XX:XX е ип адреса на l2tp сървъра, като пак повтарям клиент може да е директно Windows или Linux. Тук хватката е, че рутираш мрежата 192.168.100.0/24 където са въпросните устройства през 172.17.2.1 което е адрес в тунела на сървъра. За да работи това обаче трябва да "натнеш" интерфейса l2tp-out1 с последното правило, в противен случай трябва да рутираш и от сървъра което е малко излишно в тази ситуация.

/interface l2tp-client
add connect-to=XX:XX:XX:XX disabled=no name=l2tp-out1 user=user1 password=pass1

/ip route
add dst-address=192.168.100.0/24 gateway=172.17.2.1

/ip firewall nat
add action=masquerade chain=srcnat out-interface=l2tp-out1

В този вариант не ти трябва пренасочване на портове, ще виждаш цялата мрежа 192.168.100.0/24 през тунела, като естествено можеш да имаш повече отдалечени потребители (user1, user2)

Привет отново,

За съжаление устройствата са с някакъв embedded Linux, дори не позволяват ръчно настройване на IP - само по DHCP, иначе би било чудесно едното да dial-не един VPN.

Втората греда е в рутирането на мрежата - тъй като са зад един порт, един кабел, едно DHCP са от една мрежа и ако се рутира цялата мрежа реално 2-те устройства ще се появят зад реалното IP на другата локация. Целта е едното да остане на локация 1, другото на локация 2.

При моите опити, успях да ги излъжа до някъде, но ударих греда с маскирането. Явно логиката на устройството е - клиента се закача към порт-а, устройството му вижда IP-то и вдига 2-ра връзка директно към това IP. След маскиране, устройството в моя случaй виждаше IP-то на тунела, а не реалното IP на клиента и съответно call back-a от устройството към клиента не работеше.

"Pure routing magic" трябва .. според мен :)

Редактирано 30 Март, 2022 от Chicho Mancho

[111111]

Тъп въпрос 1: Устройството нужно ли е да се вижда навън?
Тъп въпрос 2: След като устройството работи на несменяем :1234 то какъв е проблема отвън да се вижда на : 1235?

[Chicho Mancho]

3 hours ago, 111111 said:

Тъп въпрос 1: Устройството нужно ли е да се вижда навън?
Тъп въпрос 2: След като устройството работи на несменяем :1234 то какъв е проблема отвън да се вижда на : 1235?

1 - да трябва да се вижда от Интернет от произволни IP-та.

2 - на теория може, на практика не. Очаква се сървиса да върви на този порт. Като web server, който слуша на порт 3332, няма проблем да е там, но никой няма да го ползва защото се очаква да е на 80 или 443.

[JohnTRIVOLTA]

Хмммм, така като чета все едно се опитвате да осигурите достъп до някакъв вид тънък клиент понеже те комуникират по специфичен порт със сървъра им и казвате , че са някакъв вид "някакъв embedded Linux" ?!

[111111]

Aко услугата е някаква браузерна то без проблем ще работи на едно ип и един порт през NGINX.

[Chicho Mancho]

1 hour ago, 111111 said:

Aко услугата е някаква браузерна то без проблем ще работи на едно ип и един порт през NGINX.

За мое съжаление, не работи.

[111111]

Преди 1 час, Chicho Mancho написа:

За мое съжаление, не работи.

ползвай dns не ip 

nginx

server {
listen 80;
   root /opt/htdocs/lab;
index index.html index.htm;
   server_name sait1.com;
   location / {
       try_files $uri $uri/ =404;
   }
}

server {
   listen 80;
   root /opt/htdocs/dev;
   index index.html index.htm;
   server_name sait2.dev;
   location / {
       try_files $uri $uri/ =404;
   }
}

 

apache

<VirtualHost *:80>
ServerAdmin mail@example.com
   DocumentRoot /opt/htdocs/lab
   ServerName sait1.com
   ErrorLog logs/lab.geekflare.com-error_log
   CustomLog logs/lab.geekflare.com-access_log common
</VirtualHost>

<VirtualHost *:80>
   ServerAdmin mail@xyz.com
   DocumentRoot /opt/htdocs/dev
   ServerName sait2.dev
   ErrorLog logs/gf.dev-error_log
   CustomLog logs/gf.dev-access_log common
</VirtualHost>

 

[Chicho Mancho]

14 hours ago, 111111 said:

ползвай dns не ip 

nginx

server {
listen 80;
   root /opt/htdocs/lab;
index index.html index.htm;
   server_name sait1.com;
   location / {
       try_files $uri $uri/ =404;
   }
}

server {
   listen 80;
   root /opt/htdocs/dev;
   index index.html index.htm;
   server_name sait2.dev;
   location / {
       try_files $uri $uri/ =404;
   }
}

 

apache

<VirtualHost *:80>
ServerAdmin mail@example.com
   DocumentRoot /opt/htdocs/lab
   ServerName sait1.com
   ErrorLog logs/lab.geekflare.com-error_log
   CustomLog logs/lab.geekflare.com-access_log common
</VirtualHost>

<VirtualHost *:80>
   ServerAdmin mail@xyz.com
   DocumentRoot /opt/htdocs/dev
   ServerName sait2.dev
   ErrorLog logs/gf.dev-error_log
   CustomLog logs/gf.dev-access_log common
</VirtualHost>

 

Привет,

Workaround-и не са приложими - хардуерни устройства с hardcoded портове и изисквания.

Иска си real IP и специфичен порт. За това се опитвам да отмъкна порт-а и IP-то от отдалечено място.

Всъщност имам прогрес:

- пуснах EOIP върху IP Tunnel.

- oт отдалечената страна направих bridge в който вкарах EOIP интерфейса

- от моята страна направих bridge в който вкарах интерфейса където е устройството и EOIP

- в DHCP-то вкарах 2-ри network 192.168.55.100-192.168.55.200

- направих lease-a на утройството статичен и сложих IP он 2-рата мрежа (192.168.55.101)

- за gateway IP което сложих върху bridge-a от отдалечената страна (192.168.55.1)

- dst-nat на отдалечената локация към порт-а на 192.168.55.101

Продължава да не работи , но имам добро усещане. Тъй като нямам ssh достъп до самото устройство, експериментирам с едно Kali на VM-ka с пуснат nginx в същия subnet.

[111111]

Или нещо премълчаваш или въобще не прилагаш правилно решението.
При това решение вътре в мрежата устройствата си работят с непроменени параметри.

[JohnTRIVOLTA]

Преди 15 часа, Chicho Mancho написа:

...

- пуснах EOIP върху IP Tunnel.

...

Това е безмислено, когато може да е само EoIP с адресите на IPIP които ползва?!

Редактирано 1 Април, 2022 от JohnTRIVOLTA