SoftEther VPN Azure: relaja vojo, ne malfermita pordo

Via servilo staras malantaŭ enkursigilo, kiun vi ne povas agordi, do la evidenta plano plusendi pordon ne disponeblas. VPN Azure ekzistas ĝuste por tiu situacio, kaj ĝi solvas ĝin renversante la direkton de la unua konekto: la servilo elkonektiĝas al relajo, kaj klientoj atingas la relajon anstataŭ la servilon. Kompreni tiun renverson klarigas kaj kion la servo solvas kaj ĉiun limigon, kiun vi poste trafos.

Kio ŝanĝiĝas en la vojo

Ĉe kutima aŭskultanto kliento malfermas TCP-konekton al publika adreso, kiun via enkursigilo plusendas al la servilo. Ĉe la relajo la servilo tenas elirantan konekton al la relaja infrastrukturo, kaj la relajo akceptas klientajn konektojn kaj transdonas ilian ŝarĝon al la atendanta servilo. Neniu envena pordo malfermiĝas, neniu statika adreso bezoniĝas, kaj la enkursigilo restas netuŝita. Laŭ la vidpunkto de la fajroŝirmilo la servilo estas ordinara eliranta kliento, kaj tial permesas ĝin limigaj retoj.

La relajo atribuas nomon en sia propra domajno al tiu servilo, kaj klientoj agordiĝas konektiĝi tien.

Tiu nomo apartenas al la relaja servo, kiu ne estas Microsoft Azure VPN Gateway, kvankam ambaŭ nomiĝas Azure io. Trakti ilin kiel interŝanĝeblaj produktas agordon, kiun neniu povas funkciigi.

Kiuj protokoloj postvivas la relajon

La relajo transportas la protokolon SoftEther, kaj la projekto dokumentas SSTP kiel klientan opcion, kio utilas ĉar Windows venas kun SSTP-kliento. Ĝi tamen ne fariĝas ĝenerala portanto por ĉiu aŭskultanto sur la gastiganto: OpenVPN-aŭskultanto, IPsec-respondanto kaj L2TP-servo ĉiu bezonas sian propran atingeblan finpunkton, kaj neniu el ili transportiĝas tra la relajo nur ĉar la SoftEther-servilo estas konektita.

Klientaj profiloj do montras al la relaja nomo anstataŭ al la servila adreso, kaj ekzistanta profilo konstruita por rekta konekto ne funkcios senŝanĝe. Kontrolu la liston de subtenataj klientoj por la versio, kiun vi uzas, antaŭ ol plani ĉirkaŭ protokolo, kiun la relajo ne transportas.

Kion la relajo ne faras por vi

La relajo estas transporto. Ĝi ne kreas uzantojn, virtualajn hubojn, alirpolitikojn aŭ itinerojn, kaj ĝi scias nenion pri la privataj retoj malantaŭ via servilo. Se remotaj klientoj devas atingi LAN-subreton, la servilo ankoraŭ bezonas la pontan aŭ enkursigadan agordon, la revenan vojon kaj la fajroŝirmilan politikon, kiuj tion ebligas. Interkovrantaj adresaj planoj ĉe la du finoj ankaŭ estas nevideblaj por la relajo kaj restas via problemo solvi.

Ankaŭ la subtenatajn sekurecajn agordojn vi elektas mem. La projekta dokumentaro enhavas ekzemplojn de pli malnovaj platformoj, kaj kopii malnoviĝintajn ĉifrajn aŭ atestilajn agordojn el malnova ekrankopio estas bona maniero konstrui tunelon, kiun neniu povas revizii. Uzu la aktualan gvidadon por la versio, kiun vi uzas.

Atestila validigo kaj uzanta aŭtentikigo restas respondecoj de la servilo, kaj la relajo neniam anstataŭas iun el ili.

Funkciigu ĝin kiel dependecon

Disponebleco nun inkluzivas trian partion. Kiam la relajo ne atingeblas, klientoj ne povas konektiĝi sendepende de tio, kiom sana estas via servilo, kaj la paneo aspektas kiel klienta problemo de ekstere. Observu la relajan vojon aparte de la sano de la servilo, kaj tenu dokumentitan rezervan solvon, kiel rektan aŭskultanton sur alia adreso, por la tago, kiam tio gravas.

Latenteco sekvas la geografion de la relajo anstataŭ la proksimecon de viaj uzantoj, kio indas mezuri antaŭ ol promesi interagan efikecon super ĝi.

Kontrolu la identecon de la servilo kaj poste realan aplikaĵan vojon, ne nur sukcesan konektan rubandon, kaj kontrolu, ĉu la rimedo, kiun vi bezonas, atingeblas per la adresa familio, kiun la relajo transportas. Notu la relajan nomon, la uzatan protokolon kaj la rezervan solvon, ĉar tiuj tri faktoj respondas al plej multaj estontaj demandoj pri ĉi tiu ligo.