А я сошла с ума. Какая досада.

[dil]

Задача для продвинутых сисадминов. Остальным вряд ли будет интересно.

Дано: линукс, из которого можно ходить в интернет. В этом линуксе есть виртуальная машина (Sun VirtualBox), в которой живёт Windows XP, в которой живёт клиент от корпоративного VPN-сервера. Вся эта конструкция только из-за того, что у этого VPN-сервера нет клиента под линукс.

Но в целом конструкция работает. Из виртуальной XP  видно корпоративную сеть, внутреннюю почту, внутренние сайты и вообще всё прекрасно. Кроме одного: ssh (putty) на внутреннюю машину X. До сегодня он в целом работал, но в произвольные моменты времени соединение висло. Поработать  удавалось от 5 секунд до нескольких минут. При этом VPN работает, пинги на ту же машину ходят, новые сессии на ту же машину прекрасно открываются, а вот старые виснут.

Сегодня оно работать вообще перестало. Выглядело это так:

Сначала 16-секундная задержка от начала соединения до получения баннера. А потом оно выглядит, как будто где-то не пролезают большие пакеты. Ощущение усугубляется тем, что дамп попытки соединения на сервере X показывает, что после первоначального обмена баннерами сервер настойчиво отправляет в клиента большой пакет с предлагаемыми параметрами сессии, а клиент на это ничего не отвечает. Ну или ответы до сервера не доходят.

И я уже почти собрался пойти подправить MTU, но тут обнаружилось, что если из той же виртуальной XP тем же putty пойти на хостовый линукс, включив реверсный порт-форвардинг (-R 1122:172.16.x.x:22), то из хостового линукса совершенно стандартным ssh можно пойти на 127.0.0.1:1122 и.. попасть на машину X совершенно без всяких таймаутов и других проблем. С точки зрения хостового линукса MTU на интерфейсе в виртуальную машину (vbox0) совершенно обычный – 1500.

Вот как так получается? И что с этим можно сделать?

Оригинал этой записи в личном блоге.

Comments

[kaa.livejournal.com]

хуиз фиговый. бсдшный все показывает. это слабоконтролируемые райповские сети. я сам недавно из 109 /8 получил /16.

inetnum: 109.120.0.0 - 109.120.63.255
netname: RU-OMKC-20090827
descr: Omskie kabelnye seti Ltd.
country: RU

[dil.livejournal.com]

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

[kaa.livejournal.com]

а что за система, какая версия?

[dil.livejournal.com]

я ж написал: Version 4.7.30. линукс

[mcjabberwock.livejournal.com]

мастдай, адназначна

[mcjabberwock.livejournal.com]

Где ты такую траву такие, извините, хуизы находишь?? Опять добряки-линухоиды придумали для економии трафика?

[sha90w.livejournal.com]

а написать whois -h whois.ripe.net 109.120.24.139 ?

[dil.livejournal.com]

ну да, так работает. и с -h whois.arin.net тоже :)

[motto.livejournal.com]

а вот в моем хуизе не работает --вершен, но зато про сеть эту он все говорит верно

[dil.livejournal.com]

а у тебя, небось, BSD :)

[motto.livejournal.com]

в общем, да

но кто от этого страдает?

[dil.livejournal.com]

никто, просто там другой whois

[motto.livejournal.com]

более беспощадный, разумеется?

[http://users.livejournal.com/_nik_/]

Да всё правильно, в общем, пишет.
Вот, скажем, что пишет оно мне:

[17:28 /tmp]$ whois --version [2] (nik@laptop.niksite.ru)
Version 5.0.0.

Report bugs to <md+whois@linux.it>.
[17:29 /tmp]$ whois 109.120.24.139 [0] (nik@laptop.niksite.ru)
% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf

% Note: This output has been filtered.
% To receive output for a database update, use the «-B» flag.

% Information related to '109.120.0.0 — 109.120.63.255'

inetnum: 109.120.0.0 — 109.120.63.255
netname: RU-OMKC-20090827
descr: Omskie kabelnye seti Ltd.
country: RU
…