Липсващ пропуск на PPTP: отстраняване на грешка 807 във Windows VPN

Пренасочването на TCP 1723 често отваря първата част на PPTP и оставя останалото счупено, така че Windows все още връща грешка 807 при опита. Следващият инстинкт е да се добави правило за порт 47 и точно тази стъпка похабява един следобед: GRE е номер на протокол в IP заглавката, а не порт, който таблица за пренасочване може да съпостави. Докато рутерът не пропусне протокол 47 и не го обвърже със същото повикване, тунелът не може да започне. Разделите по-долу разделят двата канала и след това ги тестват един по един.

Таблицата на портовете няма ред за номер на протокол

PPTP използва два разговора, които се провалят по различен начин. Разговорът на TCP 1723 започва повикването, предава информация за връзката и го прекратява, когато потребителят се изключи. Страната на данните работи в GRE, която IP заглавката означава с номер на протокол 47, а вътре в този тунел PPP договаря връзката, докато MS-CHAPv2 проверява идентификационните данни.

Тъй като GRE не носи заглавка на транспорта, той не излага портове, затова правило, написано за портове, няма какво да съпостави. Рутер, който пренасочва 1723, създава съответствие за тази TCP сесия и спира дотам. Фърмуерът, който се занимава с втората половина, нарича функцията пропуск на PPTP или PPTP ALG, а някои фърмуери не предлагат нито едното и никога не споменават празнината. Етикетът на квадратчето е по-маловажен от това дали протокол 47 се разпознава изобщо.

Какво съобщава Windows, когато пътят на данните умира

Грешка 807 казва, че връзката не може да бъде завършена, което на практика означава, че повикването е достигнало сървъра, а каналът за данни не се е вдигнал. Това е присъда за транспорта, а не присъда за акаунта. Грешка 691 е тази, която сочи към идентификационни данни или към несъответствие в протокола за удостоверяване, затова ви изпраща съвсем другаде.

Работете по транспорта, преди да пипате паролата. Смяната на идентификационни данни, за да гоните 807, оставя истинската повреда на място и прави следващия опит по-труден за четене.

Защо втори клиент разваля работещ тунел

Без портове, които да ги различават, устройство с NAT не може да раздели два PPTP клиента така, както разделя две HTTPS сесии. Затова много потребителски устройства позволяват едно PPTP повикване и го проследяват по адрес на източника. Лаптоп, който е работил сам, спира да завършва, щом втора машина се обади, и от страната на клиента повредата изглежда случайна. Този модел принадлежи на фърмуера и никаква промяна на профила няма да го промени.

Наблюдавайте таблицата на връзките, докато и двамата клиенти се обаждат. Ако само първият хост някога държи съответствие, рутерът е стигнал до края на възможностите си и никаква настройка от страната на клиента няма да го помръдне.

Докажете коя половина се проваля

Потвърдете, че TCP 1723 пристига, преди да промените нещо на рутера, защото този отговор решава коя половина тествате. Изпълнете това от Windows клиента срещу собственото си име на сървър. Първата команда отпечатва дали портът е отговорил, а втората се обажда без диалог, което прави повторните опити сравними.

Test-NetConnection vpn.example.com -Port 1723
rasdial "Work VPN"

Верен резултат в теста на порта означава, че контролният канал е отворен и GRE е останалият заподозрян. Грешен резултат означава, че маршрутизирането, филтърът или пренасочването са счупени и никаква промяна в GRE няма да спаси това. Страната на данните трябва да се наблюдава там, където може да се види — на сървъра или на рутера.

tcpdump -ni any proto 47

Еквивалентът в Wireshark е филтърът за показване ip proto 47, който е по-лесен за предаване на човек, който не се чувства удобно в команден ред. GRE, който пристига, без нищо да излиза в отговор, означава, че обратният път се нуждае от поправка.

Какво всъщност поправя грешката

Където рутерът показва настройката, включете пропуск на PPTP или разрешете протокол 47 явно на фърмуер, който приема правила. В RouterOS правилото за пренасочване съпоставя протокола директно, което пренасочване на базата на портове никога не би могло. Потребителският фърмуер обикновено скрива същото решение зад квадратче, понякога в настройките за сигурност, а не в пренасочването на портове. Ако такова управление не съществува, нищо от страната на клиента няма да го компенсира.

/ip firewall filter add chain=forward protocol=gre action=accept
/ip firewall filter print where protocol=gre

Смяната на PPTP е другата възможност и често по-евтината. Рутер, който сам прекратява VPN, избягва двойния NAT за входящи клиенти, а протокол, с който NAT на базата на портове вече се справя, изобщо не се нуждае от пропуск: OpenVPN през UDP, SSTP през TCP 443 или L2TP/IPsec с NAT-T, който обвива ESP в UDP 4500. PPTP също зависи от MS-CHAPv2 и документираните му слабости го правят лош избор за ново внедряване дори след като грешката изчезне.

Запишете кое правило направи разликата, защото същият сайт ще срещне същото ограничение, когато вторият потребител поиска достъп. Поправка на ниво протокол принадлежи в мрежовите бележки, където ще погледне следващият инженер.