LINUX.ORG.RU
ФорумAdmin

Виртуальный интерфейс который не падает, и который слушают демоны.


0

0

Такая ситуация, дома стоит сервачёчек, получающий инет и белый IP по PPTP (интерфейс ppp0). В связи с этим есть две проблемы:

1. Некоторые сервисы стартуют раньше чем поднимается туннель, поэтому не слушают ppp0. 2. Если туннель падает, а потом поднимается, то некоторые сервисы не слушают обращений по нему.

Посему у меня родилась идея сделать какой-нибудь виртуальный интерфейс, который не будет падать, который сервисы будут слушать всегда, и который будет пересылать данные на ppp0 будэ он доступен. Кто-нибудь делал что-то подобное? Правильно я понимаю, что мне надо делать связку TAP + Ethernet Bridge? Не будет ли проблем с включением ppp0 в состав ethernet bridge'а? Может есть какое-то другое решение? Сменить провайдера или сервисы прошу не предлагать.

★★★★★

tap это вообще не в кассу, а добавить в бридж ppp-шный интерфейс не получится нифига. Так что единственный выход - запускать "некоторые сервисы" только после поднятия ppp-интерфейса.

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

Не в кассу.

>tap это вообще не в кассу, а добавить в бридж ppp-шный интерфейс не получится нифига. Так что единственный выход - запускать "некоторые сервисы" только после поднятия ppp-интерфейса.

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

Camel ★★★★★
() автор топика
Ответ на: Не в кассу. от Camel

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

Можно написать небольшую утилиту, которая будет через libpcap цепляться к реальному интерфейсу и транслировать все пакеты в tun/tap интерфейс. Получится что-то вроде моста без участия ядра. Но это страшный костыль. Правильее исправить демоны, чтобы они корректно обрабатывали пропадаение интерфейса и запуск без него.

Deleted
()
Ответ на: комментарий от anonymous

вроде был давно патч для ядра позволяющий сделать бридж для ppp, но что щаз с ним не знаю

z0D5e8n7x
()

Была такая задача, проще всего оказалось решить внешним роутером, только и делающим, что коннектящимся по vpn (l2tp) и выставляющим сервер за ним в DMZ

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

> Была такая задача, проще всего оказалось решить внешним роутером, только и делающим, что коннектящимся по vpn (l2tp) и выставляющим сервер за ним в DMZ

Внешний-то зачем? Роутить и внутре локальной машины можно. Из pppX в тот же бридж, который его серверы слушають. Только кажется топикстартеру зачем-то нужон интерфейс целиком.

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

Целиком.

А зачем мне интерфейс целиком? Что в данном случае подразумевает "целиком" и что это для меня означает? Как можно из ppp0 рулить в bridge и что это будет за bridge?

Camel ★★★★★
() автор топика

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

DonkeyHot ★★★★★
()
Ответ на: Целиком. от Camel

> А зачем мне интерфейс целиком? Что в данном случае подразумевает
 "целиком" и что это для меня означает?

Целиком добавить интерфецс в бридж и не возиться с  роутингом и
 пробросом портов.

> ак можно из ppp0 рулить в bridge и что это будет за bridge?

Поднять мост с помощью bridge-utils. Присвоить ему адрес и 
повесить на него нужные сервисы.

Например:

ifconfig:

br0       Link encap:Ethernet  HWaddr 00:10:4B:8C:7D:34  
          inet addr:10.0.0.1  Bcast:10.0.0.255  Mask:255.255.255.0

eth0      Link encap:Ethernet  HWaddr 00:30:84:77:13:1C  
          inet addr:192.168.0.189  Bcast:192.168.0.255 Mask:255.255.255.0

netstat:
 
tcp        0      0 10.0.0.1:www            *:*                     LISTEN     10039/boa

route -n:

Destination Gateway Genmask Flags Metric Ref Use Iface
10.0.0.0        0.0.0.0         255.255.255.0   U     0      0        0 br0

iptables:

iptables -t nat -A PREROUTING -p tcp -i eth0 --dport 80 -j DNAT --to 10.0.0.1:8
iptables -A FORWARD -p tcp -i eth0 -d 10.0.0.1 --dport 80 -j ACCEPT

Проверка:

 telnet 192.168.0.189 80
Trying 192.168.0.189...
Connected to 192.168.0.189.
Escape character is '^]'.

HTTP/1.0 400 Bad Request
Date: Tue, 20 Jan 2009 11:44:55 GMT
Server: Boa/0.94.14rc21
Accept-Ranges: bytes
Connection: close
Content-Type: text/html; charset=ISO-8859-1

<HTML><HEAD><TITLE>400 Bad Request</TITLE></HEAD>
<BODY><H1>400 Bad Request</H1>
Your client has issued a malformed or illegal request.
</BODY></HTML>
Connection closed by foreign host.

anonymous
()

Интересно а что мешает слушать на интерфейсе eth0, а iptables"у сказать, чтобы кидал всё на с ppp0 на eth0 ?

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

Persist.

>AFAIR ppp раньше умел держать интерфейс поднятым постоянно, т.ч. он не падал при обрыве. см. man

Опция persist, обрабатывает обрывы связи умеренной длины. Если связь рвётся на 10 минут, то не спасает.

А про iptables это идея.

Camel ★★★★★
() автор топика

Если ip-адрес статический то для вашего случая был придуман Dummy-интерфейс, вроде его поддержку из ядра не убрали. Просто вешаете на него нужный адрес и все демоны его слушают, а когда ppp-интерфейс поднимается и получает этот же ip-адрес ppp0 и dummy "объединяются".

А если ip-адрес динамический, то, как уже сказали, DNAT.

mky ★★★★★
()
Ответ на: Persist. от Camel

>Опция persist, обрабатывает обрывы связи умеренной длины.

А у PPP адрес туннеля статический или динамический? Если статический, то попробуй demand.

Macil ★★★★★
()

Может не совсем в тему, но ещё в ядре есть параметр net.ipv4.ip_nonlocal_bind (см. sysctl -a), который позволяет делать сервисам bind на несуществующие в системе IP. Если у вас постоянный IP и сервисы вешаются именно на IP, это может помочь.

spirit ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.