SoftEther VPN Azure: en relévei, ikke en åpen port

Serveren din står bak en ruter du ikke kan konfigurere, så den åpenbare planen om å videresende en port er utilgjengelig. VPN Azure finnes nettopp for den situasjonen, og den løser den ved å snu retningen på den første forbindelsen: serveren ringer ut til et relé, og klientene når reléet i stedet for serveren. Å forstå den vendingen forklarer både hva tjenesten retter og hver grense du vil møte senere.

Hva som endres i veien

Med en vanlig lytter åpner en klient en TCP-forbindelse til en offentlig adresse som ruteren din videresender til serveren. Med reléet opprettholder serveren en utgående forbindelse til reléinfrastrukturen, og reléet godtar klientforbindelser og sender nyttelasten deres videre til serveren som venter. Ingen inngående port åpnes, ingen statisk adresse kreves, og ruteren forblir urørt. Sett fra brannmurens synspunkt er serveren en vanlig utgående klient, og det er derfor restriktive nettverk tillater den.

Reléet tildeler et navn på sitt eget domene til den serveren, og klienter konfigureres til å koble til der.

Det navnet tilhører relétjenesten, som ikke er en Microsoft Azure VPN Gateway selv om begge kalles Azure noe. Å behandle dem som utskiftbare gir en konfigurasjon som ikke kan fungere.

Hvilke protokoller som overlever reléet

Reléet transporterer SoftEther-protokollen, og prosjektet dokumenterer SSTP som et klientvalg, noe som er nyttig fordi Windows leverer en SSTP-klient. Det blir likevel ikke en generell bærer for hver lytter på verten: en OpenVPN-lytter, en IPsec-responder og en L2TP-tjeneste trenger hver sitt eget tilgjengelige endepunkt, og ingen av dem transporteres gjennom reléet bare fordi SoftEther-serveren er tilkoblet.

Klientprofiler peker derfor på relénavnet i stedet for serveradressen, og en eksisterende profil bygget for en direkte forbindelse vil ikke fungere uendret. Sjekk listen over støttede klienter for versjonen du kjører før du designer rundt en protokoll reléet ikke bærer.

Hva reléet ikke gjør for deg

Reléet er en transport. Det oppretter ikke brukere, virtuelle huber, tilgangspolicyer eller ruter, og det vet ingenting om de private nettverkene bak serveren din. Hvis eksterne klienter må nå et LAN-undernett, trenger serveren fortsatt bro- eller rutingkonfigurasjonen, returveien og brannmurpolicyen som får det til å virke. Overlappende adresseplaner i begge ender er også usynlige for reléet og forblir ditt problem å løse.

De støttede sikkerhetsinnstillingene er også dine å velge. Prosjektdokumentasjonen inneholder eksempler på eldre plattformer, og å kopiere eldre chiffer- eller sertifikatinnstillinger fra et gammelt skjermbilde er en god måte å bygge en tunnel ingen kan revidere. Bruk gjeldende veiledning for versjonen du kjører.

Sertifikatvalidering og brukerautentisering forblir serverens ansvar, og reléet erstatter aldri noen av dem.

Drift det som en avhengighet

Tilgjengeligheten omfatter nå en tredjepart. Når reléet ikke er tilgjengelig, kan klientene ikke koble til uansett hvor sunn serveren din er, og feilen ser ut som et klientproblem utenfra. Overvåk reléveien separat fra serverens egen helse, og hold en dokumentert fallback som en direkte lytter på en annen adresse for den dagen det betyr noe.

Forsinkelsen følger reléets geografi i stedet for nærheten til brukerne dine, noe det er verdt å måle før du lover interaktiv ytelse over det.

Bekreft serverens identitet og deretter en reell applikasjonsvei, ikke bare et vellykket tilkoblingsbanner, og sjekk om ressursen du trenger er tilgjengelig over adressefamilien reléet bærer. Noter relénavnet, protokollen som brukes og fallbacken, fordi disse tre faktaene besvarer de fleste fremtidige spørsmål om denne koblingen.