SoftEther VPN Azure: ein reléveg, ikkje ein open port

Tenaren din står bak ein ruter du ikkje kan konfigurere, så den openberre planen om å videresende ei port er utilgjengeleg. VPN Azure finst nettopp for den situasjonen, og han løyser han ved å snu retninga på den første sambindinga: tenaren ringjer ut til eit relé, og klientane når reléet i staden for tenaren. Å forstå den vendinga forklarer både kva tenesta rettar og kvar grense du vil møte seinare.

Kva som endrar seg i vegen

Med ein vanleg lyttar opnar ein klient ei TCP-sambinding til ei offentleg adresse som ruteren din videresender til tenaren. Med reléet held tenaren ved ein utgåande sambinding til reléinfrastrukturen, og reléet tek imot klienttilkopingar og sender nyttelasta deira vidare til tenaren som ventar. Ingen inngåande port vert opna, ingen statisk adresse er naudsynt, og ruteren er urørt. Frå brannmursynsvinkelen er tenaren ein vanleg utgåande klient, og difor tillèt restriktive nettverk han.

Reléet tildeler eit namn på sitt eige domene til den tenaren, og klientar vert konfigurerte til å kople til der.

Det namnet høyrer til relétenesta, som ikkje er ein Microsoft Azure VPN Gateway sjølv om begge vert kalla Azure noko. Å handsame dei som utskiftbare gjev ein konfigurasjon som ikkje kan fungere.

Kva protokollar som overlever reléet

Reléet transporterer SoftEther-protokollen, og prosjektet dokumenterer SSTP som eit klientval, noko som er nyttig fordi Windows leverer ein SSTP-klient. Det vert likevel ikkje ein generell berar for kvar lyttar på verten: ein OpenVPN-lyttar, ein IPsec-svarar og ei L2TP-teneste treng kvar sitt eige tilgjengelege endepunkt, og ingen av dei vert transporterte gjennom reléet berre fordi SoftEther-tenaren er tilkopla.

Klientprofilar peiker difor på relénamnet i staden for tenaradressa, og ein eksisterande profil bygd for ei direkte sambinding vil ikkje fungere uendra. Sjekk lista over støtta klientar for versjonen du køyrer før du designar rundt ein protokoll reléet ikkje ber.

Kva reléet ikkje gjer for deg

Reléet er ein transport. Det opprettar ikkje brukarar, virtuelle hubar, tilgangspolicyar eller ruter, og det veit ingenting om dei private netverka bak tenaren din. Viss eksterne klientar må nå eit LAN-undernett, treng tenaren framleis bro- eller rutekonfigurasjonen, returvegen og brannmurpolicyen som får det til å verke. Overlappande adresseplanar i begge endar er òg usynlege for reléet og vert verande di oppgåve å løyse.

Dei støtta tryggleiksinnstillingane er òg dine å velje. Prosjektdokumentasjonen inneheld døme på eldre plattformer, og å kopiere eldre chiffer- eller sertifikatinnstillingar frå eit gamalt skjermbilde er ein god måte å byggje ein tunnel ingen kan revidere. Bruk gjeldande rettleiing for versjonen du køyrer.

Sertifikatvalidering og brukarautentisering er framleis tenarens ansvar, og reléet erstattar aldri nokon av dei.

Drift det som ein avhengnad

Tilgjengelegheita omfattar no ein tredjepart. Når reléet ikkje er tilgjengeleg, kan klientane ikkje kople til uansett kor sunn tenaren din er, og feilen ser ut som eit klientproblem utanfrå. Overvak relévegen separat frå tenarens eigen helse, og hald ein dokumentert fallback som ein direkte lyttar på ei anna adresse for den dagen det betyr noko.

Forsinkinga følgjer geografien til reléet i staden for nærleiken til brukarane dine, noko det er verdt å måle før du lovar interaktiv yting over det.

Stadfest identiteten til tenaren og deretter ein reell applikasjonsveg, ikkje berre eit vellukka tilkoplingbanner, og sjekk om ressursen du treng er tilgjengeleg over adressefamilien reléet ber. Noter relénamnet, protokollen som vart brukt og fallbacken, fordi desse tre faktaa svarar på dei fleste framtidige spørsmål om denne koplinga.