Re: расщепить на несколько хостов

From

Vadim Goncharov (2:5020/400)

To

Valentin Davydov

Date

2006-12-13T16:42:38Z

Area

RU.UNIX.BSD

From: Vadim Goncharov <vadimnuclight@tpu.ru>

Hi Valentin Davydov! 

On Wed, 13 Dec 2006 07:27:21 +0000 (UTC); Valentin Davydov wrote about 'Re: расщепить на несколько хостов':

 VD>>>> А на хосту А на этот порт
 VD>>>> повесить tcp-proxy, слепленный жвачкой из inetd, netcat, bounce и т.д.
 VD>>>> и умеющий всё что ни попадя, в том числе и src ip round-robin.
 >>>>Хм, а вот тут поподробнее - как это будет выглядеть? Эти src ip таки
 >>>>придется алиасами вешать или оно (кстати, кто из связки?) умеет
 >>>>raw-сокеты?
 VD>>> Берёшь сетку, скажем, 10.40/16. Пишешь на сервере Б роутинг на эту сетку
 VD>>> так, чтобы он доходил до хоста А. Затем на хосту А ставишь все 65536 адресов
 VD>>> из этой сетки на lo0 алиасами (с маской 32, разумеется).
 >>>Почему на lo0 ?
 VD>> В общем, необязательно на lo0, можно, допустим, и на lo1, просто lo0 обычно
 VD>> уже есть в системе и не надо заботиться о его создании. А на внешние
 VD>> интерфейсы, по-моему, не стоит: зачем в сети лишний arp-трафик?
 >>Да с чего бы ему возникнуть-то? никто ведь не будет опрашивать эти
 >>адреса, поскольку они совершенно в другой подсети.
 VD> Я бы не стал говорить за всех. Винды в сети, небось, имеются, а?

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

 >>>Конечно, хотелось бы более изящно, чем куча
 >>>алиасов на одном хосте, но и это сойдет.
 VD>> Другие варианты (хитровывернутый nat, альтернативный tcp/ip стек на bpfах и
 VD>> т.д.) представляются мне ещё менее изящными.
 >>Ну почему же? При алиасах система будет проверять эту кучу алиасов для
 >>каждого входящего пакета, а при хитром нате - только для пакетов по этим
 >>соединениям, что меньше.
 VD> При нате она тоже вынуждена проверять каждый пакет на соответствие пулу
 VD> адресов. Просто чтобы выясниить, надо ли его натить или нет.

Дык, в нат заворачивается только один src-port порт входящий, что будет
существенно меньше всего трафика машины.

 >>>А какие тут могут быть тонкости? Разрешить достаточное количество
 >>>одновременных соединений, и пусть висит.
 VD>> Наиболее неприятной тонкостью, с которой я встречался, было честное висение
 VD>> nc в процессах вплоть до истечения всевозможных таймаутов при некоррректном
 VD>> обрыве tcp-соединения одной из сторон.
 >>Это при RST ?
 VD> Это при отсутствии RST, как и каких-либо других пакетов.

А, понял. Думаю, в моем случае это особой проблемой не будет.

 >>а с какой стороны он это не отработал?
 VD> Точно не помню уже, но по всей видимости со стороны сервера, раз он крив.
 VD> В итоге обошёлся ключиком -w.

Ок, учту.

-- 
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nuclight@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]
--- slrn/0.9.8.1 on FreeBSD 4.11/i386
 * Origin: Nuclear Lightning @ Tomsk, TPU AVTF Hostel (2:5020/400@fidonet)
SEEN-BY: 50/12 400/814 450/159 1024 461/43 132 640 469/999 4616/3 4625/8
SEEN-BY: 4641/444 5000/76 5000 5006/1 5007/1 5010/70 5011/13 5012/46 5015/28
SEEN-BY: 5019/26 5020/18 175 194 400 545 982 1057 1909 1922 2238 2395 2871
SEEN-BY: 5020/4441 5021/29 5025/3 5026/14 45 5027/12 5030/1080 1957 5034/10 13
SEEN-BY: 5035/3 38 5036/1 5045/7 5049/1 5051/15 5054/1 4 8 9 11 28 35 36 37 45
SEEN-BY: 5054/66 67 70 75 84 85 5059/9 5060/88 5061/15 5062/10 5063/3 5064/7
SEEN-BY: 5066/18 5075/5 5076/1 5077/70 5080/1003 5084/9 5085/13 5095/20
SEEN-BY: 5096/18 6001/10

PATH: 5020/400 545 5054/1 37