Сервер PPTP за домашнім маршрутизатором: спершу виправте 1723 і GRE

PPTP за домашнім маршрутизатором відмовляє двома не пов'язаними способами, і плутанина між ними коштує цілого вечора. Одна несправність — прогалина в перенаправленні: маршрутизатор пропускає TCP 1723 і відкидає протокол IP 47, тому клієнт висить на помилці 619. Інша — проблема розміру: тунель піднімається, проходить автентифікацію, а потім завмирає, коли має пройти пакет повного розміру. З'ясувати, яка з них у вас, — це перший справжній крок; решта порівнює, що здатен виразити ваш маршрутизатор, а не яка марка краща.

Два транспорти, і лише один має порт

PPTP поділяється на два транспорти: керівне з'єднання на TCP 1723 і кадри PPP, упаковані в розширений GRE, тобто протокол IP 47. У GRE немає номера порту, тому правило, записане як проброс порту 1723, не може його охопити, хоч би як веб-інтерфейс називав це поле. Домашній маршрутизатор зазвичай пропонує прапорець із назвою проброс PPTP замість правила протоколу, і цей прапорець робить дві речі: пропускає протокол 47 через міжмережевий екран і вчить NAT відстежувати потік GRE. На маршрутизаторі Linux ці роботи — окремі модулі й окремі правила, тому наполовину налаштований проброс усе одно дає робочий канал керування. З'ясуйте, яка половина наявна, перш ніж щось змінювати.

Власний міжмережевий екран сервера теж має дозволяти протокол 47 з адреси маршрутизатора. Міжмережевий екран хоста, що приймає лише 1723/tcp, відтворює помилку 619 зсередини LAN, і через це зламаний проброс і зламане правило хоста виглядають однаково.

sudo iptables -S FORWARD | grep -i gre
sudo nft list ruleset | grep -i gre
lsmod | grep -E 'nf_conntrack_proto_gre|nf_nat_proto_gre'

Якщо модулів немає, завантажте їх через sudo modprobe nf_conntrack_proto_gre nf_nat_proto_gre і зробіть завантаження постійним, бо перезавантаження, що забуває помічник, знову перетворює робочий тунель на помилку 619. Правило пробросу має приймати протокол 47 лише до адреси сервера, а не до всієї LAN. Визначення в RFC 2637 розділяє шлях керування та шлях даних, тому жоден екран пробросу портів не описує PPTP повністю.

Прапорець пробросу чи явне правило протоколу

Прапорець пробросу, який лише відкриває міжмережевий екран, ближчий до правильного, ніж ALG, що переписує ідентифікатори виклику. Половина з міжмережевим екраном передбачувана, бо протокол 47 або приймається, або відкидається, і лічильники кажуть, що саме. Половина з переписуванням — це місце, де виробники різняться, бо ідентифікатори виклику PPTP задаються для кожного тунелю, і NAT, який їх редагує, мусить відстежувати кожен виклик, якого торкається. Коли один клієнт підключається, а два ні, ALG — перший підозрюваний.

Правило NAT призначення для 1723 теж має проблему власника. Якщо старе правило досі надсилає 1723 на хост, який перестав запускати сервер, пакети потрапляють на закритий порт, і власна служба PPTP маршрутизатора перестає відповідати — це читається як збій міжмережевого екрана, але насправді є застарілою ціллю. Прочитайте правило та його призначення, перш ніж додавати друге. На маршрутизаторах, які самі завершують PPTP, правило WAN конкурує зі вбудованою службою, тому виберіть одного власника для 1723 і протоколу 47.

Два клієнти за одним NAT — це випадок, який відділяє простий проброс від кмітливого. Проброс протоколу 47 без переписування ідентифікаторів виклику зазвичай поводиться краще, ніж помічник, що намагається їх виправити.

Виміряйте тунель, перш ніж звинувачувати маршрутизатор

PPTP зменшує корисне навантаження, і це зменшення — арифметика, а не загадка. Кожен пакет тунелю несе зовнішній заголовок IP, розширений заголовок GRE, заголовок PPP і, з шифруванням, заголовок MPPE. Коли шлях не може провести утворений кадр, малі пакети проходять, вхід завершується, а сеанс зупиняється першого разу, коли передавання файлу або рукостискання TLS надсилає пакет повного розміру.

Порахуйте число замість здогадок. Розширений GRE коштує 8 байтів, PPP — 4, MPPE — 4, а зовнішній заголовок IP — 20, тому тунель з'їдає 36 байтів до будь-якого навантаження. На WAN з PPPoE, що закінчується на 1492, найбільший PPP MTU, який уміщається, — це 1492 мінус 36, тобто 1456. Задайте mtu і mru це значення в параметрах PPP і перевірте знову пінгом без фрагментації.

ping -M do -s 1464 198.51.100.7
grep -E '^(mtu|mru)' /etc/ppp/options.pptpd

Пінг вимірює шлях, а не тунель: 1464 байти навантаження плюс 28 байтів заголовків IP і ICMP точно заповнюють кадр у 1492 байти. Якщо цей пінг не проходить, знижуйте число, доки він не пройде, і відніміть 36 від результату. MTU тунелю, заданий вище за межу шляху, спричиняє зависання без жодного рядка журналу, де згадувався б розмір.

PPTP, L2TP/IPsec або OpenVPN на одному маршрутизаторі

Той самий маршрутизатор може нести будь-який із трьох звичайних тунелів, і різниця в тому, що він має виразити. PPTP потребує двох правил у двох різних шарах. L2TP поверх IPsec потребує UDP 500 і 4500 для обміну ключами і, якщо NAT-T його не несе, протокол 50 для навантаження. OpenVPN потребує одного порту UDP і взагалі не потребує помічника.

Стовпець L2TP не є автоматично привітнішим за GRE. ESP — це протокол IP 50, і в нього теж немає порту, тому маршрутизатор, який має труднощі з протоколом 47, може мати їх і з протоколом 50 з тієї самої причини. NAT-T існує, щоб загорнути ESP усередину UDP 4500, і коли обидва кінці це підтримують, правило протоколу 50 стає непотрібним. Це властивість кінців, а не прапорця PPTP на маршрутизаторі. Підтвердьте, яку інкапсуляцію клієнт справді узгодив, перш ніж писати правила для обох.

OpenVPN — варіант із найменшою кількістю рухомих частин на боці маршрутизатора. Один порт UDP, один проброс, жодного помічника відстеження з'єднань і жодного переписування ідентифікаторів виклику. В обмін потрібен клієнт, який слід встановити замість вбудованого дозвонювача, і часто це єдина причина, чому PPTP залишається в розмові.

Що лагодити і що замінювати

Виправлення пробросу й MTU дає робочий тунель, а не той, який варто зберігати. Автентифікація MSCHAPv2 у PPTP уразлива вже багато років, а робочий тунель передає облікові дані, які можна відновити офлайн. Якщо віддалений пристрій уміє запускати L2TP/IPsec або OpenVPN, вважайте ремонт тимчасовим заходом із датою.

Рішення зводиться до того, що підтримує дальній кінець і як довго схема має протриматися. Старий пристрій, що говорить лише PPTP, отримує ремонт; усе, куди можна встановити клієнт, мігрує.

Перш ніж закрити заявку, підтвердьте, що клієнт переживає велике передавання, а не лише вхід, і що маршрутизатор після перезавантаження досі тримає правило протоколу 47. Тунель, який проходить одну копію файлу і вмирає після наступного оновлення прошивки, ніколи не був завершений.