Как настроить SSH чтобы при редиректе портов или проксировании выбирался нужный remote ethN.Vlan

Вот тут:
https://unix.stackexchange.com/questions/16057/use-ssh-with-a-specific-networ...
и тут:
https://serverfault.com/questions/243955/opensshds-dynamic-proxy-routing-capa...

Пишут, мол программа не выбирает исходящий интерфейс, мол таблицы маршрутизации якобы выбирают,
что с моей точки зрения является бредом сивой кабылы, несмотря на то, что решения помечены «правильными».

1) В каком то смысле написанное в этих ветках соответствовало бы действительности для
проходящих пакетов, созданных на других хостах. Но несмотря на то,
что оригинальные пакеты для SSH SOCKS создаются на другом хосте (клиенте SSH)
исходящие пакеты на хосте сервера SSH как бы создаются заново, после того как их вытащили из
SOCKS туннеля? Ведь проксировние - НЕ есть маршрутизация?

2) Таблица маршрутизации разве выбирает С какого интерфейса слать пакет (с какого интерфейса пакет приходит или появляется)?
Я почему-то думал, что таблица маршрутов определяет НА какой интерфейс пакет отправлять дальше,
а не С какого он появился... Появиться может с любого, дальше маршрутизируем по факту?

3) Почему, например, ping -I XXX позволяет задать интерфейс?
почему ping -I eth0.Vlan пингирует в моем случае
а ping -I eth0 НЕ пингирует? таблица маршрутизации то одинаковая однако :) только признак VLAN появляется или нет в зависимости от выбора интерфейса зарождения пакета.

Наверно, можно, найти какую-нибудь прогу редиректа портов, где можно задать исходящий интерфейс или даже провернуть такой фокус с помощью iptables?

тогда sshd SOCKS/forwarder->second port forwarder->specific Eth->шлем откуда надо

Пишут, мол программа не выбирает исходящий интерфейс, мол таблицы маршрутизации якобы выбирают, что с моей точки зрения является бредом сивой кабылы, несмотря на то, что решения помечены «правильными».

Правильно пишут, ssh только делает connect(), исходящий адрес и интерфейс определяются таблицей маршрутизации.

1) В каком то смысле написанное в этих ветках соответствовало бы действительности для проходящих пакетов, созданных на других хостах. Но несмотря на то, что оригинальные пакеты для SSH SOCKS создаются на другом хосте (клиенте SSH) исходящие пакеты на хосте сервера SSH как бы создаются заново, после того как их вытащили из SOCKS туннеля? Ведь проксировние - НЕ есть маршрутизация?

SOCKS - это прокси, не туннель. Т.е., это такая программа, которой скармливают адрес и порт назначения, она сама туда соединяется и после передает данные между двумя концами. Это не маршрутизация, тут нет пакетов, есть только поток данных.

2) Таблица маршрутизации разве выбирает С какого интерфейса слать пакет (с какого интерфейса пакет приходит или появляется)? Я почему-то думал, что таблица маршрутов определяет НА какой интерфейс пакет отправлять дальше, а не С какого он появился... Появиться может с любого, дальше маршрутизируем по факту?

Чем «С» отличается от «НА»? Когда приходит пакет от какого-то внешнего источника, то ты не будешь выбирать, на какой интерфейс он пришел. Если это маршрутизатор, то он потом будет решать, через какой интерфейс передать полученный пакет согласно тадлице маршрутизации.

3) Почему, например, ping -I XXX позволяет задать интерфейс? почему ping -I eth0.Vlan пингирует в моем случае а ping -I eth0 НЕ пингирует? таблица маршрутизации то одинаковая однако :) только признак VLAN появляется или нет в зависимости от выбора интерфейса зарождения пакета.

Это можно сделать только от рута, и это будет работать в обход таблицы маршрутизации. И просто так это не заработает, там есть свои условности.

SOCKS ... Это не маршрутизация, тут нет пакетов, есть только поток данных.

Так я об этом и писал.

Что мешает SSHD под рутом выбрать интерфейс на котором будет появляться (телепортироваца/копироваться с клиента SSH средствами кода SSH/SSHD, а не роутингом ядра) пакет, который как я думал уже ПОСЛЕ его «телепортации» на хост SSHD ДАЛЕЕ будет отправляться в соответствии с таблицей маршрутизации этого хоста?

Это можно сделать только от рута, и это будет работать в обход таблицы маршрутизации. И просто так это не заработает, там есть свои условности.

Т.е. использование таблицы маршрутизации и принудительный выбор интерфейса (на котором создается пакет) являются взаимоисключающими?

ping -I ethX не может использовать таблицу маршрутизации хоста, на котором запущена данная команда?

почему тогда ping разных подсетей работает при указании -I eth0.100, но при этом ping -I eth0 работает ТОЛЬКО для подсети без VLAN (aka VLAN0 вроде?)?

мне кажется это можно объяснить только тем, что интерфейс зарождения пакета (локально С) - это одно, а интерфейс его отправления (локально НА) - это другое и определяется таблицей маршрутизации даже при указании -I XXX

Что мешает SSHD под рутом выбрать интерфейс

Выбирается не интерфейс, выбирается исходящий адрес. В том же пинге в опции -I можно указать адрес. Интерфейс там можно указать только для удобства.

Ну и sshd такое не поддерживает: http://serverfault.com/questions/585264/bind-outgoing-socks-server-traffic-to...

Но даже если бы и поддерживало, то только возможностями sshd ничего бы не вышло. Если у тебя есть два интерфейса, через _каждый_ из которых есть свой доступ в интернет, то для корректного разруливания надо настраивать policy routing.

В общем, тебе нужен отдельный прокси сервер, в котором реализована возможность выбора исходящего адреса. Вроде бы такое есть в 3proxy

прокси нужен для доступа к домашнему серверу, некоторые виртуалки в VLAN, к ним не пробиться с дефолтного интерфейса

другая софтина с поддержкой выбора исходящего интерфейса - скорее всего да решение, я про это и писал «second port forwarder» по тексту выше

SOCKS меня устраивает в SSHD, надо после него сделать порт forwarding с поддержкой выбора исходящего адреса, что-то типа stone/stunnel только без анврапинга SSL и с поддержкой выбора исходящего адреса :)

может посоветуете софтинку?

ИМХО, тут надо просто правильно настроить маршруты. При корректных маршрутах все должно работать. Ну и sshd будет достаточно.

Покажи схему сети, где у тебя какие адреса назначены, и какие маршруты есть.

Саша, ты жесть какую-то пишешь.
Уточни про какие интерфейсы речь и покажи вывод
ip a
ip r
ip ru
iptables-save

VLAN: виртуалки на забридженных eth0.N на хосте гипервизора (НЕ на роутере)
если внутри виртуалки поменять Айпи на другую сеть, то они как мне и хотелось, не видят эту другую сеть(например ту, что прописана у eth0), т.е. они видят только в пределах своей VLAN чего бы там пользователь не поменял в настройках интерфейса внутри виртуали
вернее в таблице arp они начинают видеть айпишники нежелательной для них сети, но связи с ними нет.

далее другой хост - роутер с несколькими интерфейсами, в т.ч.
eth0 - физический, связан через хаб кабелем с eth0 гипервизора
eth0.N (тоже на роутере) - VLAN интерфейс

вот мне надо, попав на роутер через SSH, чтобы я мог подключиться к виртуалке внутри VLAN
пока VLAN не было подключение работало, после появления VLAN
eth0 роутера больше не пингует виртуалку
eth0.N пингует, но он НЕ выбирается SSHD проксёй, вот в этом проблема

iptables-save

iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

на роутере и гипервизоре

На eth0.N роутера адрес из той же подсети, что и у виртуалок? Размер подсети такой же?

Ну и надо понимать, что в eth0 и eth0.N на гипервизоре и роутере должны быть разные подсети. Например, 192.168.1.0/24 на eth0 и там и там, 192.168.2.0/24 на eth0.N и там и там. На роутере при этом, например, поставить адреса 192.168.1.1 и 192.168.2.1, на гипервизоре 192.168.1.2 и 192.168.2.2, виртуалкам давать адреса из 192.168.2.10-192.168.2.254. После этого все должно работать

VLAN: виртуалки на забридженных eth0.N на хосте гипервизора (НЕ на роутере)

Подразумевалось:

1) На гипервизоре создаем eth0.N
2) В VirtualBox (потом со временем в KVM) прописываем bridged interface для виртуалки, который присоединен к интерфейсу eth0.N
3) Внутри виртуалки никаких VLAN не настраиваем, но при этом связь есть только с другими хостами в VLAN

Ну и надо понимать, что в eth0 и eth0.N на гипервизоре и роутере должны быть разные подсети. Например, 192.168.1.0/24 на eth0 и там и там, 192.168.2.0/24 на eth0.N и там и там. На роутере при этом, например, поставить адреса 192.168.1.1 и 192.168.2.1, на гипервизоре 192.168.1.2 и 192.168.2.2, виртуалкам давать адреса из 192.168.2.10-192.168.2.254. После этого все должно работать

Именно так

пинги с интерфейса 192.168.1.1 НЕ идут на 192.168.2.2
но как выяснилось пинги с адреса 192.168.1.1 ИДУТ на 192.168.2.2

теперь вообще ниче не понимаю ...

скриншот (адресация немного отличается):
http://picpaste.com/pics/ping-xYKQvqtQ.1484803305.jpg

Покажи вывод этих команд на роутере:

ip r
ip a

не хотелось бы в паблик

Ну только внутренние оставь. Меня интересует только относящееся к подсетям 192.168.0.0/24 и 192.168.100.0/24

ip r

192.168.0.0/24 dev eth0 proto kernel scope link src 192.168.0.1
192.168.100.0/24 dev eth0.100 proto kernel scope link src 192.168.100.1

ip a
3: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 1c:1b:0d:0d:2f:7b brd ff:ff:ff:ff:ff:ff
inet 192.168.0.1/24 brd 192.168.0.255 scope global eth0
valid_lft forever preferred_lft forever
6: eth0.100@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 1c:1b:0d:0d:2f:7b brd ff:ff:ff:ff:ff:ff
inet 192.168.100.1/24 brd 192.168.100.255 scope global eth0.100
valid_lft forever preferred_lft forever

ребутнул роутер, ничего не поменялось

роутер->виртуалка поверх eth0.100:
telnet 192.168.100.101 3389
не соединяется

роутер->гипервизор с eth0.100:
telnet 192.168.100.2 22
соединяется

кстати можно как то поднять eth0.100 на гипервизоре, но без адреса? адрес нужен только в bridged интерфейсе виртуалки

может просто выбрать какой-нибудь случайный IP из другой случайной сети для eth0.100? типа 1.2.3.4 не нужен мне дополнительный адрес гипервизора

роутер->виртуалка поверх eth0.100: telnet 192.168.100.101 3389 не соединяется

А на самой виртуалке фаерволлом не блочится случаем? Т.к. все остальное выглядит нормально.

кстати можно как то поднять eth0.100 на гипервизоре, но без адреса? адрес нужен только в bridged интерфейсе виртуалки

Можно, в случае дебиана будет выглядеть примерно так:

iface eth0 inet manual
    pre-up ip link set eth0.100 up
    post-down ip link set eth0.100 down

Поправка:

iface eth0.100 inet manual

А на самой виртуалке фаерволлом не блочится случаем? Т.к. все остальное выглядит нормально.

iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination

Chain FORWARD (policy ACCEPT)
target prot opt source destination

Chain OUTPUT (policy ACCEPT)
target prot opt source destination

У тебя внутри виртуалки линукс и там поднят RDP?

Т.к. все остальное выглядит нормально.

наверно что-то с VLAN, плохо знаком с деталями настройки и использования, только общую идею представляю

хотел чтобы в VLAN (виртуалки и один из интерфейсов роутера) была связь только с 192.168.100.x
и чтобы из 192.168.0.x не было связи с 192.168.100.x, кроме как через роутер
но как то странно все получилось ...

надо еще попробовать tracert/tcptraceroute

У тебя внутри виртуалки линукс и там поднят RDP?

венда (лицензионная) VLAN в ней не настраивал

Если telnet 192.168.100.2 22 работает, то с VLAN'ом все в порядке

Я имел в виду фаерволл в этой винде. iptables на хосте не влияет в случае бриджа.

Я имел в виду фаерволл в этой винде. iptables на хосте не влияет в случае бриджа.

в венде был выключен файрвол, я его не включал, соединение раньше работало, когда венда была в сетке 192.168.0.x

А нельзя ли каким нибудь флагом ядра отключить изоляцию VLAN друг от друга, но при этом оставить виртуальные интерфейсы типа eth.100 ? отложить настройку до лучших времен, а пока просто оставить как есть без VLAN изоляции.

А нельзя ли каким нибудь флагом ядра отключить изоляцию VLAN друг от друга

Номер VLAN'а в ethernet кадр записывается, так что нет. Это равносильно перевешиванию виртуалок обратно на eth0

Попробуй настроить vlan в винде, глянь что будет после этого.

Это равносильно перевешиванию виртуалок обратно на eth0

этого и хотелось бы, но без слома текущих настроек

Попробуй настроить vlan в винде

тоже была такая мысль

Для маршрута можно задать адрес источника, который будет использоваться системой при формировании пакета.

Если систему застваить использовать этот маршрут, то задача будет решена. Делать это при помощи policy-routing или еще каким-нибудь образом - решать тебе.

почему ping -I eth0.Vlan пингирует в моем случае

tcpdump -e -i eth0 dst 192.168.100.101
показывает следующее:

ethertype 802.1Q (0x8100), length 46: vlan 100, p 0, ethertype ARP, Reply atom is-at (oui Unknown), length 28

видим VLAN 100, связь есть, все ок

а ping -I eth0 НЕ пингирует

tcpdump: (oui Unknown) > Broadcast, ethertype ARP (0x0806), length 42: Request who-has 192.168.100.101 tell atom, length 28

видим, роутер шлет запросы и не может найти искомое в дефолтном VLAN

в предыдущем сообщении VLAN работает ожидаемо, и вывод tcpdump соответствовал ожиданиям,

но почему тогда в следующем тесте с tcptraceroute в логе tcpdump всегда видим vlan 100 ?

tcptraceroute -i eth0 192.168.100.101 -n
Selected device eth0, address 192.168.100.1, port 43707 for outgoing packets
Tracing the path to 192.168.100.101 on TCP port 80 (http), 30 hops max
1 * * *
2 * * *
3 *^C

tcptraceroute -i eth0.100 192.168.100.101 -n
Selected device eth0.100, address 192.168.100.1, port 58965 for outgoing packets
Tracing the path to 192.168.100.101 on TCP port 80 (http), 30 hops max
1 192.168.100.101 [open] 0.357 ms 0.198 ms 0.232 ms

получается трейсы с eth0 (это транк?) ожидаемо не идут, а трейсы с eth0.100 ожидаемо идут, но tcpdump -e -i eth0 dst 192.168.100.101 всегда видит vlan 100, как так?

и внезапно заработала связь от SSH SOCKS в сторону VLAN 100, это COOL хацкеры ночью что-то отремонтировали ? )

я сам в этом направлении пока ничего не менял в настройках

а может это полиси роутинг с виртуалки отправлял весь траф наружу в инет через другой туннель tun101 - персональный для этой виртуали, и SOCKS тупо обламывался получить ответ даже на локальном IP ? )

или такого быть не может? потому как зачем слать пакет с dst=192.168.x.x в VPN, когда этот айпи присутствует на роутере?

скриптик для policy routing:

http://pastebin.com/XnUbMmFf

чета я не пайму, фсе туннели, файрволы и policy routing фключены

праблема решилась сама собой?

ога ребутнул роутер и не работает уже :(

как выяснилось надо было разрешить в файрвол после ребута

но возникает тогда вапроз,

линукс стал таким же стабильным как венда?

вчера то ведь я вообще отключал файрвол на всех задействованных хостах

сегодня сначала работало со включенным файрволом

потом после ребута и включения логирования увидел такое:

atom kernel: [ 6411.809450] FIREHOL: OUT-VMs:IN= OUT=eth0.100 SRC=192.168.100.1 DST=192.168.100.101 LEN=84 TOS=0x00 PREC=0x00 TTL=64 ID=42256 DF PROTO=ICMP TYPE=8 CODE=0 ID=20030 SEQ=285

на роутере добавил правило (временно пока так):
interface eth0.100 VMs;
server all accept;
client all accept;

ну и заработало опять

Так у тебя там еще и policy routing, зря я не стал спрашивать :D

Ядро старое? ЕМНИП, в версиях около 3.2 и старше надо было делать ip route flush cache после изменений.

Ядро старое? ЕМНИП, в версиях около 3.2 и старше надо было делать ip route flush cache после изменений.

uname -a
Linux atom 4.6.0-0.bpo.1-amd64 #1 SMP Debian 4.6.4-1~bpo8+1 (2016-08-11) x86_64 GNU/Linux

ip route flush cache делается, см ссылку на скрипт выше по тексту