Windows VPN adreses laukā norādītais ports darbojas tikai ar SSTP

VPN serveris atbild uz TCP 10443, iebūvētajam Windows klientam ir pareizi akreditācijas dati, un savienojums tomēr pārtrūkst pēc pauzes, kas izskatās pēc DNS taimauta. Iemesls parasti ir adreses lauks: ierakstot vpn.example.com:10443 laukā Servera nosaukums vai adrese, Windows nolasa visu virkni kā resursdatora nosaukumu, jo šis lauks nav vispārīga host:port ievade. Vai ports tur vispār ir izsakāms, ir atkarīgs no tuneļa veida, ko izmanto profils, un tikai viens no četriem veidiem uzskata vērtību par kaut ko, ko tas spēj parsēt.

Kāpēc adreses lauks nav host:port lauks

Profila rekvizīts aiz šī lauka ir ServerAddress, un katrs tuneļa veids izlemj, ko tas dara ar virkni. Trim no tiem nav porta parametra, ko aizpildīt, tāpēc kols un skaitlis ir vienkārši rakstzīmes nosaukumā, kas nekad netiks atrisināts. Ceturtais darbojas caur HTTPS, kur ports ir URL daļa, tāpēc vērtība jāraksta tādā formā, kas tiek parsēta kā URL.

Tāpēc kļūme izskatās pēc nosaukumu atrisināšanas, nevis pēc noraidīta savienojuma. Nav neviena slikta porta, par ko ziņot, ir tikai neeksistējošs resursdatora nosaukums, un kļūda pienāk pēc tam, kad atrisinātājs padodas. Pirms pieskaraties serverim, pārbaudiet, kādu tuneļa veidu profils apgalvo, ka izmanto.

Trīs veidi ar fiksētu portu

PPTP pieslēdzas TCP 1723 un pēc tam pārnēsā tuneli GRE, IP protokolā 47. L2TP/IPsec izmanto UDP 1701 tunelim un UDP 500 plus 4500 IPsec, kur 4500 ir NAT šķērsošanas ports. IKEv2 izmanto arī UDP 500 un 4500. Neviens no šiem profiliem nekur saskarnē neparāda porta lauku, un neviens nepārrunās nestandarta portu.

Serveris, kas klausās pielāgotā portā, tāpēc šiem profiliem nav sasniedzams neatkarīgi no tā, kā adrese ir uzrakstīta. Praktiskās atbildes ir šauras: publicējiet standarta portu serverī vai pārtulkojiet standarta portu uz pielāgoto portu maršrutētājā tā priekšā. Abi variantu profilu klientam atstāj neskartu, kas daudz vērts, ja profils tiek izvietots ar politiku, nevis rakstīts ar roku.

SSTP vajag URL, nevis nosaukumu

SSTP ir izņēmums, jo tas darbojas TLS sesijā. Laukam jābūt parsētam kā URL: vispirms https:// shēma, tad resursdators, tad kols un ports. Bez shēmas Windows turpina uzskatīt vērtību par vienkāršu nosaukumu, un savienojums pārtrūkst pirms jebkādas TLS apmaiņas.

Iemesls, kāpēc tas pārsteidz cilvēkus, ir tas, ka noklusējuma ports pieņem kailu resursdatora nosaukumu. Profils, kuram nekad nav vajadzējis pielāgotu portu, nekad neiemāca likumu, un pirmais cilvēks, kas to pievieno, atklāj to caur neveiksmi. Pēc saglabāšanas nolasiet saglabāto vērtību, nevis paļaujieties uz dialogu:

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

ServerAddress parāda tieši to, kas tika saglabāts. Ja tas lasās kā kails resursdatora nosaukums ar kolu, profils nekad nesaņēma URL, un nekāds atkārtojumu skaits to neizlabos.

Ražotāja sintakse, ko ielīmē tajā pašā laukā

Dažas vārtejas dokumentē papildu konvencijas šim laukam, piemēram, reālu, kas pievienots pēc porta, vai vaicājuma parametrus, kas maina sertifikātu apstrādi. Tos saprot attiecīgā ražotāja serveris un dažās būvēs arī tā paša klients. Tie nav daļa no Windows profila formāta, un to ielīmēšana iebūvētā profilā parasti rada to pašu kluso nosaukuma kļūdu.

Parametru, kas atspējo sertifikātu validāciju, uzskatiet par brīdinājumu, nevis par labojumu. Ja profils pieslēdzas tikai ar šo parametru, sertifikāts neatbilst izmantotajam nosaukumam, un pareizais labojums ir vārtejā, nevis klientā. Reāls pēc porta ir ar tādu pašu īpašību: tas kaut ko dara tikai tad, ja serveris otrā pusē to gaida.

Pierādiet portu, tad nolasiet neveiksmīgo posmu

Pirms vainojat profilu, pārliecinieties, ka kaut kas pieņem TCP šajā portā no klienta tīkla:

Test-NetConnection vpn.example.com -Port 10443

Panākumi pierāda klausītāju, nevis SSTP. Tīmekļa serveris, apgrieztais starpniekserveris vai slodzes balansētājs var pabeigt TCP rokasspiedienu un joprojām nerunāt ar SSTP, tāpēc zaļš tests ar sarkanu VPN ir reāla kombinācija. Salīdziniet sertifikāta subjektu ar nosaukumu profilā un pārbaudiet RasClient žurnālu būvēs, kurās tas ir iekļauts, jo tas reģistrē neveiksmīgo posmu, nevis vispārīgu taimautu.

Pēc tam apsveriet iespēju, kas problēmu novērš, nevis dokumentē: pāradresējiet TCP 443 no ārpuses uz 10443 VPN serverī. Tad klients izmanto noklusējuma profilu bez jebkāda porta, kas parasti ir tīrākais risinājums pārvaldītai flotei un atstāj pielāgoto portu kā iekšēju detaļu.