Помощь с роутингом

между ними НЕ поднята локалка и поднять её нет возможности

через ssh-туннель тоже никак?

ничего не понятно, в смысле канал есть, а локалки нет?

Мысль хороша. Сейчас опробую.

Сенкс.

Заморочка с Policy на сети провайдера.

Что-то не соображу...

# ssh -D 777 user@host

http://localhost:777/

Невозможно загрузить веб-страницу, так как не поступили данные от сервера.

ЧЯДНТ?

эмм, я не про port forwarding, я про полноценный туннель

PermitTunnel yes

Если честно, не нашел у себя в конфиге sshd_conf такого (debian).

так пропиши

Ух. Чуть не положил удалённую машину. Лучше, проверю на виртуалках, а потом уже попробую поднять.

Я так понимаю, всё что касается бриджа в этой статье можно упустить для моего случая?

да, просто описать для двух интерфейсов на каждой машине подъем tap-а в preup-е

например так:

auto tap5                                                                                                                              
iface tap5 inet manual
      pre-up tunctl -u username -t $IFACE
      post-down tunctl -d $IFACE
      address 192.168.1.1                                                                                                                                                
      netmask 255.255.255.0          
      

Ну и опцию в конфиг ssh

Сделал так.

При исполнении

ssh -o Tunnel=Ethernet -w7:8 admin@192.168.0.1

туннель не поднимется. ifup везде сделал, ssh перезапустил. Просто заходим на сервер и все...

Tunnel device open failed. Could not request tunnel forwarding.

пишет?

номера tap-ов правильные? tap7 на клиенте, tap8 на сервере?

Не пишет.

Да, верный. Он их просто не поднимает.

то есть туннелей нет? uml-utilities стоят? А если вручную попробовать выполнить команду на создание?

socks-proxy

#!/bin/bash

while true
do
    ssh -CTNv -D <IP-ADDRESS>:443 localhost
    sleep 1
done

В фурифоксе в настройках прописать в SOCKS5 <IP-ADDRESS>:443

Не забудь фуриволом заблочить ненужных если айпи торчит наружу.

Жопа есть, а слова нет :)

я в курсе, но сокс-прокся неудобна - её нужно везде прописывать (плюс не все её умеют). А то - роут прописал и юзай наздоровье

да.

Я думаю, это связано с inet manual. Если указать inet static, то с клиета до сервера будет недостутачаться, но интерфейсы поднимутся.

а если не прописывать в interfaces, создать всё руками и запихнуть в скрипт?

Ну это самый простой и быстрый способ для обхода закрытых портов и выкачивания поррентов. Плюс работает через любой хост в инторнете. Раут же ограничивается локалкой и прёт весь траффик.

Я думаю, проще заморочится с VPN.

Пока сделал по изначальному способу и как подсказал wlan. На нетбуке не завелось, ибо хромиум был собран без поддержки прокси.

Проблема в том, что когда tap с подсетью, в которой находится сервер поднимается на клиенте, он перестает видеть сервер. Руками это делать, или через interfaces. no rout to host и всё тут.

Я ведь правильно полагаю, что vpn туннель будет лучше, чем ssh туннель?

Плюс работает через любой хост в инторнете.

не-а, не через любой

Раут же ограничивается локалкой и прёт весь траффик.

не весь, а который пропишешь

Я думаю, проще заморочится с VPN.

если было бы проще - я бы давно заморочился. А так - уже два раза подрывался делать и не доводил до конца, слишком много телодвижений. С ssh - поставить пару пакетов да поправить три конфига.

когда tap с подсетью, в которой находится сервер поднимается на клиенте, он перестает видеть сервер

по внешнему адресу или по адресу tap-а?

Я ведь правильно полагаю, что vpn туннель будет лучше, чем ssh туннель?

ну, как минимум в одном - да: не будет инкапсуляции tcp через tcp. Хз правда, чем это плохо (3 года использую подобное туннелирование - брат жив). Бродкасты ходят, ipv6 через radvd получается. Чего ещё надо?

не-а, не через любой

Я имел ввиду хост у которого у тебя есть доступ.

не весь, а который пропишешь

тяжело зараутить траффик на гугл через отдельный гейтвей.

Я имел ввиду хост у которого у тебя есть доступ.

у меня как-то был халявный шелл (не помню где), на котором туннелирование и редирект портов резали

Каким образом интересно.

Да, по внешнему адресу.

Немного уточню. Я могу достучатся до сервера по серому адресу, пусть будет 192.168.0.1. Почему так, отдельная песня. Но, в данном случае, его как бы можно считать и внешним.

На сервере, настроен eth0 192.168.0.1 и tap8 192.168.0.1. На стороне клиента настроен tap7 192.168.0.2. Хм, я подумал, а не нужен ли на стороне клиента бридж в таком случае? На стороне клиента стоит роутер, поднимающий pppoe сессию и локалка 172.16.0.0/24.

Просто, проблема в том, что когда на клиенте поднимается tap7, он перестает видеть сервер...

ping 192.168.0.1 no rout.

eth0 192.168.0.1 и tap8 192.168.0.1.

и ты щеё хочешь, чтобы это работало?

Да, протупил... Значит, на сервере поднимать tap с ip, например 10.10.0.1, а на клиенте 10.10.0.2.

А пакеты с 10.10.0.1 в 192.168.0.1 в таком случае как будут форвардится?

sshuttle подойдёт?

не совсем понял

на клиенте прописываешь

ip route add 192.168.0.1 via старыйшлюз
ip route add default(ну или любую нужную подсеть) via 10.10.0.1

а, ну и не забыть на сервере маскарадинг(например) + форвардинг настроить

А чем bonding не подходит?

А каким боком его сюда?