Вход:  Пароль:  
FreeSource: AfanasovDmitry/Сеть/FirewallДляТуннелей ...
Free Source | Каталог | Изменения | НовыеКомментарии | Пользователи | Регистрация |

Опять-таки, не только у меня возникли проблемы с открытием туннельного трафика в firewall'е.


Оглавление документа

Оглавление документа AfanasovDmitry/Сеть/ОрганизацияТуннелей?

1. ipgre туннели

Как и ipip – самый простой туннель. Создаётся более чем просто:


Замечания

  1. если <ipaddr> указазать в виде, напрмер, 192.168.2.40/30, то автоматически создастся маршрут в scope link. Как и всюду, его не будет, если маска будет 32. И придётся ip route запускать вручную
  2. если использовать [dev <device>], то gre пакеты будут приниматься только с этого девайса (в зависимости от rp_filter)

ipip туннели устанавливаются точно также.


Всё, туннель настроили. Теперь firewall.
Для начала надо разрешить трафик между <localip> и <peerip>. Разрешать можно не всё, а только gre протокол (в /etc/protocols он за номером 47). А затем трафик по на интерфейсе <tunnelname>. Правила будут выглядеть примерно так:


Кстати, в FORWARD в endpoint'ах обрабатывать протокол gre не надо Трафик вида <localip> <
> <peerip> будет приходить в только в INPUT.


Для ipip тоже самое. только лишь протокол будет 94 (если верить /etc/protocols)


И iptables и tcpdump понимают именование протокала как gre. То есть они спокойно проглотят tcpdump proto gre и iptables -p gre

2. PPTP туннели

Уфф. с этим на самом деле почти тоже самое. Одно но: на pptpd сервере надо разрешить подключения на 1723 порт, или что там слушает pptpd.


Как оказалось, pptpd аутентификацию и всё остальное проделывает по tcp протоколу: для этого и нужен 1723 порт. А вот сам трафик гуляет как ip_gre, только обрабатывает его не ядро, а pptpd. Так что обработка происходит точно также как и в случае ip_gre.


Замечание вот уж не знаю как, но в случае с pptpd у меня трафик прекрасно проходил через NAT. С ip_gre туннелем такое не прокатит. А значит на NAT box'ах в FORWARD имеет смысл регулировать gre протокол.


Замечание Если же pptp не проходит через NATbox, тогда спасает modprobe ip_nat_pptp

3. PPP over SSH 

Ну тут просто: весь трафик болтается по ssh подключению. Так что если есть возможность залогинится на машину, то ничего больше открывать не надо.

3.1. SSH port-forwarding

Nick Grechukh:
не обязательно использовать PPP, достаточно штатного port forwarding:
ssh remote.host.org -g -R 8080:192.168.1.1:80 – демон ssh на *удаленном* хосте будет слушать порт 8080 и передавать пакеты *локальному для нас* ssh, который их отдаст *локальному* (ближнему к нам) 192.168.1.1 на порт 80. Ключ -g разрешает подключения с других машин (иначе порт доступен только с самой удаленной машины)


ssh remote.host.org -g -L 8080:192.168.1.1:80 – *локальный* процесс ssh будет слушать локальный порт 8080, пакеты форвардить демону на remote.host, который их отдаст ближнему к себе 192.168.1.1 на порт 80.


«ближний к себе» – любая машина доступная с соответствующего хоста. Если речь идет о локалхосте (моем или удаленном), то можно ставить 127.0.0.1. Я выбрал серые адреса для локальной и удаленной сетей специально в целях демонстрации – т.е. 192.168.1.1 рядом со мной и 192.168.1.1 рядом с удаленной машиной это разные хосты. При -L речь идет о 192.168.1.1 из удаленной сети, при -R – из локальной ко мне.


Перенаправление абсолютно прозрачно, в обоих случаях подкючение к tcp/8080 соответствующих хостов выглядит как обычный веб-сервер.
Используя эту технологию можно например делать ssh-over-ssh – подключение по цепочке. Или пробросив порт 3128, использовать прокси. Все в ваших руках :)


Решение для прохода по цепочке:
сеть 192.168.1.*, в мир смотрит маршрутизатор имеющий внешний адрес xx.xx.xx.xx. В сети есть сервер 192.168.1.100, имеющий доступ к подсети 172.16.10.0, в которой есть машина 172.16.10.20 и веб-сервер 172.16.10.40. Я нахожусь снаружи:

откроется веб сервер 172.16.10.40, причем с точки зрения сервера, запрос исходит от .20.


AfanasovDmitry /19.08.2005 14:56/
Блин, хоть подписались бы что ли :)


port-forwarding я так и не использовал, поэтому как он работает знаю только в теории. Например что такое «ближний к себе 192.168.1.1» – это мой locahost, или может быть третьей машиной? И так как я с ним ещё не работал, я и не писал. Так что в любом случае спасибо за отметку :)


Все «но» по такому подключению я отмечу в ОрганизацияТуннелей?. А они есть – в одном моём случае? он бы не прошёл :)


Nick Grechukh:
еще есть socks, который можно пробросить указанным способом, и уже в него заворачивать все что нужно


 
Файлов нет. [Показать файлы/форму]
Один комментарий. [Показать комментарии/форму]