SoftEther VPN Azure: relejaus kelias, o ne atviras prievadas

Jūsų serveris yra už maršrutizatoriaus, kurio negalite konfigūruoti, todėl akivaizdaus prievado persiuntimo plano nėra. VPN Azure egzistuoja būtent tokiai situacijai ir sprendžia ją apgręždamas pirmojo ryšio kryptį: serveris išeina į relejį, o klientai pasiekia relejį, o ne serverį. To apgręžimo supratimas paaiškina ir ką paslauga išsprendžia, ir kiekvieną apribojimą, su kuriuo vėliau susidursite.

Kas keičiasi kelyje

Su įprastu klausytuvu klientas atidaro TCP ryšį į viešą adresą, kurį jūsų maršrutizatorius persiunčia serveriui. Su releju serveris palaiko išeinantį ryšį į relejų infrastruktūrą, o relejis priima klientų ryšius ir perduoda jų naudingąją apkrovą laukiančiam serveriui. Joks įeinantis prievadas neatidaromas, nereikia statinio adreso, o maršrutizatorius lieka nepaliestas. Ugnies sienos požiūriu serveris yra paprastas išeinantis klientas, todėl ribojantys tinklai jį leidžia.

Relejis priskiria tam serveriui vardą savo domene, o klientai sukonfigūruojami jungtis ten.

Tas vardas priklauso relejų tarnybai, kuri nėra Microsoft Azure VPN Gateway, nors abi vadinamos Azure kuo nors. Traktuojant jas kaip keičiamas gaunama konfigūracija, kuri negali veikti.

Kurie protokolai išgyvena relejį

Relejis perduoda SoftEther protokolą, o projektas dokumentuoja SSTP kaip kliento parinktį, kas naudinga, nes Windows turi SSTP klientą. Tačiau jis netampa bendru pernešėju kiekvienam pagrindinio kompiuterio klausytuvui: OpenVPN klausytuvui, IPsec atsakikliui ir L2TP tarnybai kiekvienam reikia savo pasiekiamo galinio taško, ir nė vienas jų neperduodamas per relejį vien todėl, kad SoftEther serveris prijungtas.

Todėl klientų profiliai nurodo relejaus vardą, o ne serverio adresą, o esamas profilis, sukurtas tiesioginiam ryšiui, neveiks nepakeistas. Prieš projektuodami aplink protokolą, kurio relejis neperduoda, patikrinkite palaikomų klientų sąrašą jūsų naudojamai versijai.

Ko relejis už jus nepadaro

Relejis yra transportas. Jis nesukuria vartotojų, virtualiųjų šakotuvų, prieigos taisyklių ar maršrutų ir nieko nežino apie privačius tinklus už jūsų serverio. Jei nuotoliniai klientai turi pasiekti LAN potinklį, serveriui vis tiek reikia sujungimo arba maršrutizavimo konfigūracijos, grįžimo kelio ir ugnies sienos taisyklės, kurios tai leidžia. Persidengiantys adresų planai abiejuose galuose taip pat nematomi relejui ir lieka jūsų sprendžiama problema.

Palaikomus saugumo nustatymus taip pat renkatės jūs. Projekto dokumentacijoje yra senesnių platformų pavyzdžių, o pasenusių šifravimo ar sertifikatų nustatymų kopijavimas iš seno ekrano vaizdo yra geras būdas sukurti tunelį, kurio niekas negali audituoti. Naudokite galiojančias rekomendacijas jūsų naudojamai versijai.

Sertifikatų tikrinimas ir naudotojų autentifikavimas lieka serverio atsakomybe, o relejis niekada nepakeičia nė vieno iš jų.

Eksploatuokite kaip priklausomybę

Prieinamumas dabar apima trečiąją šalį. Kai relejis nepasiekiamas, klientai negali prisijungti nepriklausomai nuo to, koks sveikas jūsų serveris, ir gedimas iš išorės atrodo kaip kliento problema. Stebėkite relejaus kelią atskirai nuo serverio būklės ir laikykite dokumentuotą atsarginį variantą, pavyzdžiui, tiesioginį klausytuvą kitame adrese, dienai, kai tai bus svarbu.

Vėlavimas seka relejaus geografiją, o ne jūsų naudotojų artumą, ką verta išmatuoti prieš žadant interaktyvų našumą per jį.

Patikrinkite serverio tapatumą, o paskui tikrą programos kelią, ne tik sėkmingą prisijungimo juostą, ir patikrinkite, ar reikiamas išteklius pasiekiamas per adresų šeimą, kurią perduoda relejis. Užsirašykite relejaus vardą, naudotą protokolą ir atsarginį variantą, nes šie trys faktai atsako į daugumą būsimų klausimų apie šią jungtį.