Клиенты PPTP на DD-WRT не видят друг друга: пять проверок
Маска 255.255.255.255 на PPP-соединении верна. Пройдите пять проверок по порядку: пул, запись CHAP, маршруты партнёров, политика FORWARD и намерение насчёт интернета.
Два ноутбука подключаются к серверу PPTP на устройстве DD-WRT, каждый получает адрес, и ни один не может пингануть другой. Общие папки не появляются, и первая мысль — что маска 255.255.255.255, которую выдаёт роутер, наверняка неверна. Это не причина, и её замена не создаст ни одного нового соседа. Пройдите пять проверок ниже по порядку и остановитесь, как только одна провалится, потому что у каждой своё лекарство.
Проверка первая: /32 — не ошибка
PPTP несёт PPP, а соединение PPP связывает ровно две точки: ваш клиент и сервер. Маска сети описывает, какие адреса делят локальный сегмент, а здесь сегмента нет, только партнёр на другом конце одного провода. Маска из одних единиц говорит именно это, поэтому DD-WRT выдаёт правильное значение для такого типа соединения. Адрес — это адрес партнёра, а не адрес интерфейса в LAN.
Маска 255.255.255.0 принадлежит общей среде с сотнями устройств, и её установка на интерфейс PPP тоже не сделает другую сторону туннеля соседом.
Проверка вторая: прочитайте значения на странице сервера PPTP
Все важные настройки находятся в разделе Службы, VPN, Сервер PPTP. Включите сервер, задайте адрес сервера равным LAN-адресу роутера и держите диапазон клиентов вне пула DHCP, чтобы клиент, который дозванивается, и проводная машина не получили один и тот же адрес. В разделе CHAP-Secrets добавьте по одной строке на каждую учётную запись в виде username * password *, без пробелов внутри имени. Примените, затем подключитесь профилем, в котором указаны роутер и одна из этих записей.
То, где клиент останавливается, подсказывает, какой уровень проверять. Клиент, который проходит аутентификацию, но не получает адрес, — это проблема пула или секретов; клиент, который получает адрес и ничего не достигает, — проблема маршрутизации или межсетевого экрана.
Проверка третья: поищите маршрут между двумя партнёрами
Каждый туннель, заканчивающийся на роутере, — это собственный интерфейс, обычно ppp0, ppp1 и так далее. Трафик от одного клиента к другому должен маршрутизироваться между этими интерфейсами, и роутер должен быть готов его пересылать. Выполните ip route на роутере и поищите маршрут к хосту для каждого подключённого партнёра, указывающий на соответствующий интерфейс PPP. Если у партнёра нет маршрута, туннель не поднят полностью, что бы ни утверждал экран состояния клиента.
Два маршрута к хостам через два отдельных интерфейса ppp — именно та картина, которая нужна, прежде чем идти дальше.
Проверка четвёртая: смотрите цепочку FORWARD, а не INPUT
Трафик между клиентами пересылается, а не принимается локально, поэтому цепочка INPUT — неправильное место. Выполните iptables -L FORWARD -v -n и поищите правило отбрасывания, которое ловит интерфейсы PPP, а также счётчики пакетов, показывающие, доходит ли до цепочки хоть что-нибудь. Политика отбрасывания по умолчанию без правила приёма для туннельного трафика даёт ровно тот симптом, с которого вы начали: каждый клиент по отдельности в порядке, вместе они невидимы друг для друга.
Если маленькие пинги работают, а большие передачи застревают, туннель фрагментируется, а не блокируется. PPTP поверх PPP обычно хочет MTU и MRU около 1450, а если оставить их на 1500, получится соединение, которое проходит рукопожатия и падает на реальной нагрузке.
Проверка пятая: решите, что должен делать доступ в интернет
Клиентам, которым нужно ходить в сеть через офис, нужна трансляция адреса источника в сторону интерфейса WAN. Клиентам, которым нужно дотянуться только до LAN, нужен маршрут и больше ничего. Это разные намерения с разными наборами правил, и вопрос о маске полностью скрывает это второе решение. Запишите, какое поведение вы хотели, прежде чем добавить хотя бы одно правило, потому что клиент, неожиданно выходящий через офисную линию, — это сюрприз, который всплывает на совещании, а не в журнале.
Последнее замечание, не связанное с исправлением: PPTP устарел, и его аутентификация сломана уже много лет. Список выше по-прежнему объясняет, что делает соединение PPP, и те же рассуждения применимы, если позже переведёте клиентов на современный туннель.