Каверзный вопросик для системных администраторов

[dil]

Дано: маленькая одноранговая виндовая локальная сеть. Доменный контроллер, WINS, DHCP, всё как обычно. Всё подключено через одни общий неуправляемый коммутатор. IP-адреса из блока 10.0.0.0/24.

Шлюзом в интернет работает юниксовая машина. Она же по совместительству работает VPN-концентратором (PPTP) для внешних клиентов. Адреса выдаёт из той же сети 10.0.0.0/24, чтобы подключившиеся клиенты прозрачно видели локальную сеть.

Никакой фильтрации трафика для локальных IP-адресов ни на самом шлюзе, ни на внутренних серверах нет.

Проблема: клиент успешно подключается по PPTP, получает адрес, но из всей локальной сети видит только сам шлюз. Все остальные попытки соединиться с любыми серверами в локальной сети или даже запустить traceroute натыкаются на таймауты со следующего хопа после шлюза.

В то же время соединения с самогО шлюза на те же внутренние серверы успешно устанавливаются.

Форвардинг на шлюзе, естественно, включён. Анализ с помощью tcpdump на шлюзе показывает, что пакеты из VPN успешно форвардятся в локальную сеть, но ответы на них не приходят. proxyarp включён.

Вопрос: кто виноват, что делать?

Upd: ответ под катом

А дело в том, что добрые администраторы при переносе PPTP-сервера с доменного контроллера на юникс скопировали туда и пул динамических адресов. В результате DHCP-сервер в локалке и PPTP-сервер выдавали адреса из одного диапазона. И когда pptp-клиент получал адрес, уже имеющийся в локалке, оно нифига и не работало, поскольку локальная машина успевала отвечать на ARP-запросы раньше, и все ответы уходили в неё.

Увидеть это со шлюза затруднительно, потому что для него на этот динамический адрес был явный маршрут через ppp*, и искать его через ARP шлюз даже и не пытался. А посмотреть что-либо с других машин в локалке тоже было затруднительно, потому что на них из VPN попасть было нельзя.

Оригинал этой записи. Комментировать можно тут или там.

Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме

Comments

[dil.livejournal.com]

так вот именно что должны. а пакеты от машинок из LAN в шлюз приходят только на его личный IP. а на IP впнных клиентов не приходят

[dmarck.livejournal.com]

можешь всё-таки показать кусочек tcpdump -e? потому что явно фигня какая-то.

[dil.livejournal.com]

не, тогда ты сразу догадаешься :)

[dmarck.livejournal.com]

фуй, какой ты. ;-P

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

[dil.livejournal.com]

не, маска везде /24, и мак он отдаёт свой, как положено.

[dil.livejournal.com]

см. апдейт

[mik1.livejournal.com]

если proxyarp настроен ровно, то только файрвол
я аналогичным образом постоянно нарывался при deny all

[dil.livejournal.com]

нету файрвола для локальных адресов, это в условии задачи написано.

[mik1.livejournal.com]

у неуправляемого свитча залипает таблица arp?

[dil.livejournal.com]

не, со свитчом всё хорошо. со шлюза всё нормально работает.

[mik1.livejournal.com]

mtu/mru/mss? я не помню чего там за нюансы у pppd, ибо все на mpd строю

[dil.livejournal.com]

нет. даже мелкие пинги не работают

[mik1.livejournal.com]

мак точно от правильного езера клиенту в LAN отдается?

[dil.livejournal.com]

точно. откуда там другой возьмётся..

[dmarck.livejournal.com]

У неуправляемого свитча нет таблицы ARP, за исключением управляющего интерфейса ;-P

[dil.livejournal.com]

как это нет? тогда это не свитч, а хаб

[dmarck.livejournal.com]

У него есть таблица маков, но нет связи ея с третьим уровнем ;-P

[dil.livejournal.com]

ну ладно :)
в общем, с таблицей всё нормально

[dmn42.livejournal.com]

Откуда у неуправляемого свича управляющий интерфейс? %)

[dil.livejournal.com]

а я ему и возражаю: логично!