SoftEther VPN Azure: releja ceļš, nevis atvērts ports

Jūsu serveris atrodas aiz maršrutētāja, kuru nevarat konfigurēt, tāpēc acīmredzamais porta pāradresācijas plāns nav pieejams. VPN Azure pastāv tieši šādai situācijai, un tā to atrisina, apgriežot pirmā savienojuma virzienu: serveris zvana uz releju, un klienti sasniedz releju, nevis serveri. Šīs apgriešanas izpratne izskaidro gan to, ko pakalpojums atrisina, gan katru ierobežojumu, ar ko vēlāk saskarsieties.

Kas mainās ceļā

Ar parastu klausītāju klients atver TCP savienojumu uz publisku adresi, ko jūsu maršrutētājs pārsūta serverim. Ar releju serveris uztur izejošu savienojumu uz releja infrastruktūru, un relejs pieņem klientu savienojumus un nodod to kravu gaidošajam serverim. Netiek atvērts neviens ienākošs ports, nav vajadzīga statiska adrese, un maršrutētājs paliek neskarts. Ugunsmūra skatījumā serveris ir parasts izejošs klients, tāpēc ierobežojoši tīkli to atļauj.

Relejs piešķir šim serverim vārdu savā domēnā, un klienti tiek konfigurēti savienoties tur.

Šis vārds pieder releja pakalpojumam, kas nav Microsoft Azure VPN Gateway, lai gan abus sauc par Azure kaut ko. Uzskatot tos par aizvietojamiem, tiek iegūta konfigurācija, kas nevar darboties.

Kuri protokoli iztur releju

Relejs pārsūta SoftEther protokolu, un projekts dokumentē SSTP kā klienta opciju, kas ir noderīgi, jo Windows piegādā SSTP klientu. Tas tomēr nekļūst par vispārēju pārvadātāju katram resursdatora klausītājam: OpenVPN klausītājam, IPsec atbildētājam un L2TP pakalpojumam katram vajadzīgs savs sasniedzams galapunkts, un neviens no tiem netiek pārsūtīts caur releju tikai tāpēc, ka SoftEther serveris ir pievienots.

Tāpēc klientu profili norāda uz releja vārdu, nevis servera adresi, un esošais profils, kas veidots tiešam savienojumam, nedarbosies bez izmaiņām. Pirms projektējat ap protokolu, ko relejs nepārsūta, pārbaudiet atbalstīto klientu sarakstu jūsu izmantotajai versijai.

Ko relejs jūsu vietā nedara

Relejs ir transports. Tas neveido lietotājus, virtuālos centrmezglus, piekļuves politikas vai maršrutus, un neko nezina par privātajiem tīkliem aiz jūsu servera. Ja attāliem klientiem jāsasniedz LAN apakštīkls, serverim joprojām vajadzīga tilta vai maršrutēšanas konfigurācija, atgriešanās ceļš un ugunsmūra politika, kas to ļauj. Pārklājošies adrešu plāni abos galos arī ir relejam neredzami un paliek jūsu risināma problēma.

Atbalstītos drošības iestatījumus arī izvēlaties jūs. Projekta dokumentācijā ir vecāku platformu piemēri, un novecojušu šifrēšanas vai sertifikātu iestatījumu kopēšana no veca ekrānuzņēmuma ir labs veids, kā uzbūvēt tuneli, ko neviens nevar auditēt. Izmantojiet aktuālos norādījumus jūsu izmantotajai versijai.

Sertifikātu validācija un lietotāju autentifikācija paliek servera atbildība, un relejs nekad neaizstāj nevienu no tiem.

Ekspluatējiet to kā atkarību

Pieejamība tagad ietver trešo pusi. Kad relejs nav sasniedzams, klienti nevar savienoties neatkarīgi no tā, cik vesels ir jūsu serveris, un kļūme no ārpuses izskatās kā klienta problēma. Uzraugiet releja ceļu atsevišķi no servera veselības un turiet dokumentētu rezerves variantu, piemēram, tiešu klausītāju citā adresē, tai dienai, kad tas būs svarīgi.

Aizture seko releja ģeogrāfijai, nevis jūsu lietotāju tuvumam, ko ir vērts izmērīt pirms interaktīvas veiktspējas solīšanas tam pāri.

Pārbaudiet servera identitāti un pēc tam reālu lietojumprogrammas ceļu, ne tikai veiksmīgu savienojuma joslu, un pārbaudiet, vai nepieciešamais resurss ir sasniedzams pār adrešu saimi, ko pārsūta relejs. Pierakstiet releja vārdu, izmantoto protokolu un rezerves variantu, jo šie trīs fakti atbild uz lielāko daļu nākotnes jautājumu par šo saiti.