PPTP сървър зад домашен рутер: първо оправете 1723 и GRE
Пуснете PPTP зад домашен рутер: TCP 1723, IP протокол 47, квадратчето за пропускане и аритметиката на MTU, плюс кога L2TP или OpenVPN е по-добрата сделка.
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 байта преди какъвто и да е товар. На PPPoE WAN, който спира на 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 порт и никакъв помощник.
| Tunnel | What the router must allow | Practical note |
|---|---|---|
| PPTP | TCP 1723 and IP protocol 47 | Two transports, two rules |
| L2TP/IPsec | UDP 500, UDP 4500, protocol 50 without NAT-T | ESP has no port either |
| OpenVPN | UDP 1194 or a chosen TCP port | Single rule, no helper |
Колоната на 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 след рестарт. Тунел, който минава едно копиране на файл и умира след следващата актуализация на фирмуера, никога не е бил завършен.