SoftEther VPN Azure: edastustee, mitte avatud port

Teie server asub ruuteri taga, mida te ei saa seadistada, seega ilmne plaan porti edasi suunata ei ole kättesaadav. VPN Azure on loodud täpselt selle olukorra jaoks ja lahendab selle esimese ühenduse suuna pööramisega: server helistab välja relee poole ja kliendid jõuavad releeni, mitte serverini. Selle pöörde mõistmine selgitab nii seda, mida teenus parandab, kui ka iga piirangut, millega hiljem kokku puutute.

Mis teel muutub

Tavapärase kuulaja puhul avab klient TCP-ühenduse avaliku aadressiga, mille teie ruuter serverile edasi suunab. Relee puhul hoiab server väljuvat ühendust relee taristuga ning relee võtab vastu kliendiühendusi ja edastab nende koormuse ootavale serverile. Sissetulevat porti ei avata, staatilist aadressi ei nõuta ja ruuter jääb puutumata. Tulemüüri seisukohast on server tavaline väljuv klient, mistõttu piiravad võrgud seda lubavad.

Relee määrab sellele serverile nime oma domeenis ja kliendid seadistatakse sinna ühenduma.

See nimi kuulub releeteenusele, mis ei ole Microsoft Azure VPN Gateway, kuigi mõlemat nimetatakse Azure millekski. Nende käsitlemine vahetatavatena annab seadistuse, mis ei saa toimida.

Millised protokollid releest läbi lähevad

Relee transpordib SoftEtheri protokolli ja projekt dokumenteerib SSTP kliendivalikuna, mis on kasulik, sest Windowsiga tuleb kaasas SSTP klient. Sellest ei saa aga hosti iga kuulaja üldine kandja: OpenVPN-i kuulaja, IPsec-vastaja ja L2TP-teenus vajavad igaüks oma kättesaadavat lõpp-punkti ning ühtegi neist ei transpordita relee kaudu vaid seetõttu, et SoftEtheri server on ühendatud.

Seetõttu osutavad kliendiprofiilid relee nimele, mitte serveri aadressile, ja otseseks ühenduseks loodud olemasolev profiil ei tööta muutmata kujul. Enne, kui kavandate protokolli ümber, mida relee ei kanna, kontrollige toetatud klientide loendit teie kasutatava versiooni jaoks.

Mida relee teie eest ei tee

Relee on transport. See ei loo kasutajaid, virtuaalseid jaotureid, juurdepääsupoliitikaid ega marsruute ning ei tea midagi teie serveri taga olevatest privaatvõrkudest. Kui kaugkliendid peavad jõudma LAN-i alamvõrku, vajab server endiselt silla- või marsruutimisseadistust, tagasiteed ja tulemüüri poliitikat, mis selle toimima paneb. Kattuvad aadressiplaanid mõlemas otsas on samuti relee jaoks nähtamatud ja jäävad teie lahendada.

Ka toetatud turvaseaded on teie valida. Projekti dokumentatsioon sisaldab vanemate platvormide näiteid ning pärandkrupto- või sertifikaadiseadete kopeerimine vanalt ekraanipildilt on hea viis ehitada tunnel, mida keegi auditeerida ei saa. Kasutage teie versiooni jaoks kehtivat juhist.

Sertifikaatide valideerimine ja kasutajate autentimine jäävad serveri vastutuseks ning relee ei asenda kunagi kumbagi.

Käitage seda sõltuvusena

Kättesaadavus hõlmab nüüd kolmandat osapoolt. Kui relee ei ole kättesaadav, ei saa kliendid ühendust, olenemata sellest, kui terve teie server on, ja rike näeb väljastpoolt välja kliendiprobleemina. Jälgige relee teed serveri enda tervisest eraldi ja hoidke dokumenteeritud varulahendust, näiteks otsest kuulajat teisel aadressil, selle päeva jaoks, mil see loeb.

Latentsus järgib relee geograafiat, mitte teie kasutajate lähedust, mida tasub mõõta enne, kui lubate selle kaudu interaktiivset jõudlust.

Kontrollige serveri identiteeti ja seejärel tõelist rakenduseteed, mitte ainult õnnestunud ühenduse riba, ning vaadake, kas vajalik ressurss on kättesaadav aadressiperekonna kaudu, mida relee kannab. Märkige üles relee nimi, kasutatud protokoll ja varulahendus, sest need kolm fakti vastavad enamikule tulevastele küsimustele selle lingi kohta.