Недостаје 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 passthrough или 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, који је лакше предати некоме коме shell није удобан. GRE који стиже а ништа не одлази као одговор значи да пут повратка треба поправити.

Шта заправо исправља грешку

Тамо где рутер излаже поставку, укључите PPTP passthrough, или на фирмверу који прихвата правила изричито дозволите протокол 47. На RouterOS правило forward директно повезује протокол, што прослеђивање засновано на портовима никада не би могло. Потрошачки фирмвер обично крије исту одлуку иза поља за потврду, понекад под безбедносним поставкама уместо под прослеђивањем портова. Ако такав надзор не постоји, ништа на страни клијента га не надокнађује.

/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, чије документоване слабости га чине лошим избором за нову поставку чак и након што грешка нестане.

Запишите које је правило направило разлику, јер ће исто место наићи на исто ограничење када други корисник затражи приступ. Исправка на нивоу протокола припада мрежним белешкама, где ће погледати следећи инжењер.