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

[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

[dmarck.livejournal.com]

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

включён proxyarp не до конца. ;-P

как выглядят арп-таблицы на всех трёх точках?

[dil.livejournal.com]

до конца он включён.

на клиенте неважно, у него роутинг идёт в p-t-p-интерфейс, там арп не нужен
на остальных не знаю, у меня туда сейчас доступа нет

[dmarck.livejournal.com]

А LAN-клиент вообще шлюз про адрес тебя (за VPN) по арпу спрашивает?

[mik1.livejournal.com]

+1, или отфильтрован случайно в сторону LAN

при правильно включенном proxyarp машинки из LAN должны видеть arp всех машинок из VPN на юниксе

[dil.livejournal.com]

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

[alexkuklin.livejournal.com]

+1 про proxyarp
конфиг pppd в студию :)

[dil.livejournal.com]

да ничего особенного:

/etc/pptpd.conf:
option /etc/ppp/pptpd-options
logwtmp
localip 10.0.0.2
remoteip 10.0.0.128-191

/etc/ppp/pptpd-options:
name pptpd
refuse-pap
refuse-chap
refuse-mschap
require-mschap-v2
require-mppe-128
ms-dns 10.0.0.1
ms-wins 10.0.0.1
proxyarp
nodefaultroute
debug
lock
nobsdcomp
novj
novjccomp
nologfd
auth
plugin winbind.so
ntlm_auth-helper "/usr/bin/ntlm_auth --helper-protocol=ntlm-server-1 --require-membership-of='...'"

[alexkuklin.livejournal.com]

а маршруты/arp на других машинах в офисе как выглядят?

[dmarck.livejournal.com]

стоп-стоп, а проксиарп

>nodefaultroute

[dmn42.livejournal.com]

А pptp клиент отсылает пакетики куда надо, в пптп сервер?

[zavetrom.livejournal.com]

роутинг походу.
а точнее - не верно указан шлюз по умолчанию на клиентах.
что-то вроде того, что dhcp дает шлюз на доменконтроллер, а надо - на линуксовый гейт.
а выходит то, что пакеты обратно идут по другому маршруту, чем пакеты туда, и зарубаются роутером.

[dmarck.livejournal.com]

Это по-хорошему не должно мешать, потому как VPNclients single-hop reachable, и в default gateway уходить не должны вовсе...

[dil.livejournal.com]

с роутингом всё нормально. на клиенте весь трафик на 10.0.0.0/24 завёрнут в vpn, а локальная сеть одноранговая - там промахнуться некуда. тем более, на запросы с самого шлюза все нормально отвечают

[dmn42.livejournal.com]

static arp на клиентах?
адреса пересекаются?

[dil.livejournal.com]

static arp нету, ибо нафиг не нужен, вот адреса таки да, пересекаются :)
поэтому ответ пока спрячем, пусть остальные погадают :)

Дурацкая мысль

[kuznets-stepan.livejournal.com]

С MTU/MRU все в порядке?

Re: Дурацкая мысль

[dil.livejournal.com]

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

[pupkin-brat.livejournal.com]

а можно traceroute из локалки к vpn-client

[dil.livejournal.com]

не-а, туда коннекты не работают, включая rdp

[aol985.livejournal.com]

виноват шлюз, и, по ходу, именно в том, что выдаваемые адреса из той же сети и он считает, что их не надо роутить. Точно помню, что у фряшного ppp где-то даже про это специальный раздел был, что-то типа arp proxy.

[dil.livejournal.com]

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

[alz421.livejournal.com]

Ну да, сначала сами создадим себе трудности, а потом будем героически с ними бороться :)))
Нефиг pptp клиентов в ту же подсеть садить.

[dil.livejournal.com]

ыыы? я же сказал: сеть ВИНДОВАЯ. ты представляешь, какой геморрой будет с NBTшным ресолвингом имён, если клиенты будут в другой подсети?

[dmarck.livejournal.com]

О-о, я подозревал что-то такое.

А разве ликнукса не имеют привычку писать в ядролог о факте флипа мак-адреса у одного айпишнега? Фря бы уже оборалась.

[dil.livejournal.com]

ежели б оно было внутри локалки, на езернете, то написал бы. а тут оно переехало из широковещательной сети в point-to-point, где мака нету..