LINUX.ORG.RU
Форум — Admin  

переадресация запросов


0

1

Более общий вопрос, навеянный тем, что я спрашивал вчера.

Допустим у меня есть два компьютера ip1 и ip2. ip1 виден всем, ip2 виден только ip1. Нужно сделать, чтобы запрос приходящий на порт n компьютера ip1 переадресовывался на порт k компьютера ip2.

Вопросы:

  • Как это называется ? Это и есть port forwarding ?
  • Как это настраивается ?

Ну и еще сразу дополнильные вопрос - можно ли сделать и как, чтобы авторизация происходила по ssh ключам и развернуты они были на ip2?

То есть, запрос приходит на ip1, переадресуется на ip2, там проверяется ssh ключ и обратно по цепочке возвращается ответ.

Заранее спасибо.

★★
← Не монтируется шара на запись
Как сделать resize файловой системы, раскатанной на всё блочное устройство? →

port forwarding это в терминологии всяких маршрутизаторов типа D-Link, в Линуксе это называлось DNAT. По этому слову гуглить/смотреть примеры.

Настраивается всё просто, основная проблема вознкает, когда на ip2 маршрут по умолчанию идёт не через ip1 и ответный от ip2 пакет идёт другим путём, чем пакет с запросом.

То есть, запрос приходит на ip1, переадресуется на ip2, там проверяется ssh ключ и обратно по цепочке возвращается ответ.

Я не понял этой схемы. Когда настраивается DNAT, то tcp-сессия (поверх которой работет ssh) будет фактически установлена с ip2 и ip1 в ней участия не принимает. Что там внутри этой сессии ip1 не узнает, поэтому если нужно, чтобы ip1 узнавал возвращаемый ответ о проверке ключа, то это не получится.

mky ★★★★★
()

Допустим у меня есть два компьютера ip1 и ip2. ip1 виден всем, ip2 виден только ip1. Нужно сделать, чтобы запрос приходящий на порт n компьютера ip1 переадресовывался на порт k компьютера ip2.

и что дальше? Ну придёт запрос, кто и кому будет отвечать? Как пойдёт ответ?

что я спрашивал вчера.

откуда я знаю, какую тупость ты вчера спрашивал?

Ну и еще сразу дополнильные вопрос - можно ли сделать и как, чтобы авторизация происходила по ssh ключам и развернуты они были на ip2?

авторизация кого и где?

То есть, запрос приходит на ip1, переадресуется на ip2, там проверяется ssh ключ и обратно по цепочке возвращается ответ.

это можно. Если ты залогинешься на ip1. Но ты похоже хочешь чего-то другого.

emulek ★
()
Ответ на: комментарий от mky

Спасибо.

Давай, попробуем практический пример (пусть самый простейший).

У меня есть две машины:

  • ip = 172.17.0.2 (здесь поднят web сервер)
  • ip = 172.17.0.3 (здесь ничего не поднято, но с этой машины точно пингуется 172.17.0.2)

Берем третью машину и в браузере открываем 172.17.0.2 - получаем web страницу.

Теперь я хочу, чтобы при открытии http://172.17.0.3 в браузере эта машина переадресовывала этот запрос на 172.17.0.2 и возвращала мне туже самую страницу.

На машине 172.17.0.3 я делаю:

root@6d2de436eef0:/# sysctl net.ipv4.ip_forward=1
net.ipv4.ip_forward = 1
root@6d2de436eef0:/# iptables -t nat -F PREROUTING
root@6d2de436eef0:/# iptables -t nat -A PREROUTING -d 172.17.0.3 -j DNAT --to-destination 172.17.0.2 
root@6d2de436eef0:/# iptables -F FORWARD
root@6d2de436eef0:/# iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
root@6d2de436eef0:/# iptables -A FORWARD -m conntrack --ctstate NEW -d 172.17.0.2 -j ACCEPT
root@6d2de436eef0:/# iptables -P FORWARD DROP

Проверяю - не работает. Что я сделал не так ?

Спасибо за помощь.

lemas ★★
() автор топика
Ответ на: комментарий от lemas

все правильно mky написал:

Настраивается всё просто, основная проблема вознкает, когда на ip2 маршрут по умолчанию идёт не через ip1 и ответный от ip2 пакет идёт другим путём, чем пакет с запросом.

victorb ★★
()
Ответ на: комментарий от black_13

Вот вывод tcpdump на 172.17.0.3 http://pastebin.com/B74Ya63q

Практически сразу после его запуска я обновил страничку в браузере.

Честно говоря, мне это ни о чем не говорит, но надеюсь на вашу помощь

lemas ★★
() автор топика
Ответ на: комментарий от lemas

Наверное я сам виноват - не все рассказал, а похоже это может иметь значение.

Обе эти машины 172.17.0.2 и 172.17.0.3 - docker контейнеры. Соответсвенно, на хосте:

$ ifconfig
docker0   Link encap:Ethernet  HWaddr fe:69:ac:53:70:53  
          inet addr:172.17.42.1  Bcast:0.0.0.0  Mask:255.255.0.0
          inet6 addr: fe80::f0ee:53ff:feae:aa6c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:162525 errors:0 dropped:0 overruns:0 frame:0
          TX packets:278054 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:10471915 (10.4 MB)  TX bytes:436185034 (436.1 MB)

eth0      Link encap:Ethernet  HWaddr f0:de:f1:27:7a:e6  
          inet addr:172.20.0.136  Bcast:172.20.0.255  Mask:255.255.255.0
          inet6 addr: fe80::f2de:f1ff:fe27:7ae6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:16023892 errors:0 dropped:0 overruns:0 frame:0
          TX packets:4007904 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:8557520703 (8.5 GB)  TX bytes:484890281 (484.8 MB)
          Interrupt:20 Память:f8500000-f8520000 

eth1      Link encap:Ethernet  HWaddr 82:ea:96:9d:48:88  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)
lemas ★★
() автор топика
Ответ на: комментарий от lemas

Да, я, наверное, даже понимаю в чем проблема - вот чуть более причесанный tcpdump - http://pastebin.com/47MRWqXy

Запрос приходит вот в таком виде:

13:18:00.145645 IP 172.17.42.1.39735 > bb3ff912e8ce.http: Flags [S]...
13:18:00.145713 IP 172.17.42.1.39735 > 172.17.0.2.http: Flags [S]...

Здесь не 172.17.0.3, а какой-то 172.17.42.1.39735 (что это кстати, вообще за адрес такой странный?), который скорее всего принадлежит виртуальному адаптеру на хостовой машине.

Но вот как поправить правила - я не понимаю.

lemas ★★
() автор топика
Ответ на: комментарий от lemas

Здесь не 172.17.0.3, а какой-то 172.17.42.1

А почему должен быть 172.17.0.3? Это же src-адрес SYN-пакета, адрес с которого браузер пытается установить соединение.

который скорее всего принадлежит виртуальному адаптеру на хостовой машине.

Если верить выводу ifconfig, то да, пренадлежит. Но, слышать от вас «скорее всего» как то странно. Вы что, отправляя сообщении даже не пытаетесь определить кому пренадлежит ip-адрес в вашем же tcpdump'е?

То, каким путём пойдёт пакет можно выяснить медитацией над таблицей маршрутизации (″ip route″), в более сложных случаях ещё и ″ip rule″.

Ссылка, которую привёл anonymous как бы правильная, только через-чур категоричная. SNAT-правило самый грубый метод решения проблемы, потому, что:

чтобы сервер XXX.XXX.XXX.XXX думал, что пакеты к нему приходят от нашего сервера-посредника,

может быть проблемой, если на сервере XXX.XXX.XXX.XXX нужны , (допустим для fail2ban) реальные логи, а не фикция, когда все запросы с адреса YYY.YYY.YYY.YYY. Тогда возникают всякие изощрения с policy based routing, CONNMARK и т.д.

mky ★★★★★
()
Ответ на: комментарий от lemas

я хочу, чтобы при открытии http://172.17.0.3 в браузере эта машина переадресовывала этот запрос на 172.17.0.2 и возвращала мне туже самую страницу.

с этим прекрасно справляется nginx, вот и сделай проксирование запросов. мануалов в гугле море.

Komintern ★★★★★
()
Ответ на: комментарий от Komintern

Обычно так и делал с HTTP/HTTPS трафиком.

Но сейчас меня интересует более общий случай. Насколько, скажем, это нормально проксировать ssh с помощью nginx ?

lemas ★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← Не монтируется шара на запись
Admin
Как сделать resize файловой системы, раскатанной на всё блочное устройство? →