Клієнти PPTP на DD-WRT не бачать одне одного: п'ять перевірок

Два ноутбуки підключаються до сервера 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, і ті самі міркування діють, якщо згодом переведете клієнтів на сучасний тунель.