Windows VPN-ի հասցեի դաշտում նշված պորտն աշխատում է միայն SSTP-ի հետ

Սերվերի անվան դաշտը host:port չէ։ PPTP-ն, L2TP-ն և IKEv2-ն ֆիքսված պորտեր ունեն. SSTP-ն պորտն ընդունում է միայն որպես ամբողջական https:// URL, իսկ 443-ի փոխանցումը ավելի մաքուր է։

VPN սերվերը պատասխանում է TCP 10443-ով, Windows-ի ներկառուցված հաճախորդն ունի ճիշտ մուտքային տվյալներ, և միացումը այնուամենայնիվ կտրվում է DNS-ի ժամկետի ավարտ հիշեցնող դադարից հետո։ Պատճառը սովորաբար հասցեի դաշտն է. vpn.example.com:10443-ը Սերվերի անվան կամ հասցեի դաշտում գրելիս Windows-ը ողջ տողը կարդում է որպես հոսթի անուն, քանի որ այդ վանդակը ընդհանուր host:port մուտք չէ։ Թե արդյոք պորտն այնտեղ ընդհանրապես արտահայտելի է, կախված է պրոֆիլի օգտագործած թունելի տեսակից, և չորս տեսակներից միայն մեկն է արժեքը դիտարկում որպես մի բան, որը կարող է վերլուծել։

Ինչու հասցեի դաշտը host:port վանդակ չէ

Այդ դաշտի հետևում գտնվող պրոֆիլի հատկությունը ServerAddress-ն է, և թունելի յուրաքանչյուր տեսակ ինքն է որոշում՝ ինչ անել տողի հետ։ Դրանցից երեքը լրացնելու պորտի պարամետր չունեն, ուստի երկու կետը և թիվը պարզապես նիշեր են անվան մեջ, որը երբեք չի լուծվի։ Չորրորդն աշխատում է HTTPS-ի վրայով, որտեղ պորտը URL-ի մասն է, ուստի արժեքը պետք է գրվի այնպիսի ձևով, որը վերլուծվի որպես URL։

Այդ պատճառով խափանումը նման է անունների լուծման, ոչ թե մերժված միացման։ Հաղորդելու վատ պորտ չկա, կա միայն գոյություն չունեցող հոսթի անուն, և սխալը գալիս է այն բանից հետո, երբ լուծիչը հանձնվում է։ Սերվերին դիպչելուց առաջ ստուգեք, թե պրոֆիլը որ թունելի տեսակն է հայտարարում։

Ֆիքսված պորտով երեք տեսակները

PPTP-ն միանում է TCP 1723-ին, ապա թունելը տանում GRE-ով, IP 47 արձանագրությամբ։ L2TP/IPsec-ը թունելի համար օգտագործում է UDP 1701, իսկ IPsec-ի համար՝ UDP 500 և 4500, ընդ որում 4500-ը NAT-ի անցման պորտն է։ IKEv2-ը նույնպես օգտագործում է UDP 500 և 4500։ Այդ պրոֆիլներից ոչ մեկը ինտերֆեյսում ոչ մի տեղ պորտի դաշտ չի ցուցադրում, և ոչ մեկը չի բանակցի ոչ ստանդարտ պորտի շուրջ։

Այսպիսով, հատուկ պորտով լսող սերվերը անհասանելի է այդ պրոֆիլների համար, անկախ նրանից, թե ինչպես է գրված հասցեն։ Գործնական պատասխանները նեղ են՝ հրապարակեք ստանդարտ պորտը սերվերի վրա, կամ թարգմանեք ստանդարտ պորտը հատուկի վրա դրա դիմացի երթուղղիչում։ Երկուսն էլ հաճախորդի պրոֆիլը թողնում են անձեռնմխելի, ինչը շատ արժեքավոր է, երբ պրոֆիլը տեղադրվում է քաղաքականությամբ, այլ ոչ թե ձեռքով մուտքագրվում։

SSTP-ն URL է պահանջում, ոչ անուն

SSTP-ն բացառություն է, որովհետև աշխատում է TLS նստաշրջանի ներսում։ Դաշտը պետք է վերլուծվի որպես URL՝ նախ https:// սխեման, ապա հոսթը, ապա երկու կետ և պորտը։ Առանց սխեմայի Windows-ը շարունակում է արժեքը դիտել որպես սովորական անուն, և միացումը ձախողվում է մինչև TLS փոխանակումը։

Մարդկանց զարմացնելու պատճառն այն է, որ լռելյայն պորտն ընդունում է մերկ հոսթի անունը։ Պրոֆիլը, որ երբեք հատուկ պորտի կարիք չի ունեցել, այդ կանոնը երբեք չի սովորեցնում, և առաջին մարդը, ով մեկն ավելացնում է, դա բացահայտում է ձախողմամբ։ Պահելուց հետո կարդացեք պահված արժեքը՝ վանդակին վստահելու փոխարեն.

Get-VpnConnection -Name "Corporate SSTP" | Select-Object Name, ServerAddress, TunnelType

ServerAddress-ը ցույց է տալիս հենց այն, ինչ պահվել է։ Եթե այն կարդացվում է որպես երկու կետով մերկ հոսթի անուն, պրոֆիլը երբեք URL չի ստացել, և որքան էլ կրկնեք փորձը, դա չի ուղղվի։

Նույն վանդակում փակցվող արտադրողի շարահյուսությունը

Որոշ դարպասներ այդ դաշտի համար լրացուցիչ պայմանավորվածություններ են փաստագրում, օրինակ՝ պորտից հետո ավելացված realm կամ հարցման պարամետրեր, որոնք փոխում են վկայականների մշակումը։ Դրանք հասկանում է այդ արտադրողի սերվերը և որոշ կառուցումներում նաև նրա սեփական հաճախորդը։ Դրանք Windows-ի պրոֆիլի ձևաչափի մաս չեն, և դրանք ներկառուցված պրոֆիլում փակցնելը սովորաբար տալիս է նույն լուռ անվանական խափանումը։

Վկայականների ստուգումն անջատող պարամետրին վերաբերվեք որպես նախազգուշացման, ոչ թե ուղղման։ Եթե պրոֆիլը միանում է միայն այդ պարամետրով, վկայականը չի համապատասխանում օգտագործվող անվանը, և ճիշտ վերանորոգումը դարպասի վրա է, ոչ թե հաճախորդում։ Պորտից հետո realm-ը նույն հատկությունն ունի. այն ինչ-որ բան անում է միայն այն դեպքում, երբ մյուս կողմի սերվերը դա սպասում է։

Ապացուցեք պորտը, ապա կարդացեք ձախողվող փուլը

Նախքան պրոֆիլին մեղադրելը հաստատեք, որ հաճախորդի ցանցից ինչ-որ բան ընդունում է TCP այդ պորտում.

Test-NetConnection vpn.example.com -Port 10443

Հաջողությունը ապացուցում է լսողի գոյությունը, ոչ թե SSTP-ն։ Վեբ սերվերը, հակադարձ վստահված անձը կամ բեռնվածքի հավասարակշռողը կարող են ավարտել TCP ձեռքսեղմումը և այնուամենայնիվ չխոսել SSTP, ուստի կանաչ թեստը կարմիր VPN-ի հետ իրական համակցություն է։ Համեմատեք վկայականի սուբյեկտը պրոֆիլի անվան հետ և ստուգեք RasClient մատյանը այն կառուցումներում, որտեղ այն կա, որովհետև այն գրանցում է ձախողված փուլը՝ ընդհանուր ժամկետի փոխարեն։

Ապա դիտարկեք այն տարբերակը, որը վերացնում է խնդիրը՝ փաստագրելու փոխարեն. փոխանցեք TCP 443-ը դրսից դեպի 10443 VPN սերվերի վրա։ Այն ժամանակ հաճախորդը օգտագործում է լռելյայն պրոֆիլը՝ առանց ոչ մի պորտի, ինչը սովորաբար ամենամաքուր լուծումն է կառավարվող նավատորմի համար և հատուկ պորտը թողնում է որպես ներքին մանրամասնություն։

Առնչվող հոդվածներ