SoftEther VPN Azure: en relævej, ikke en åben port

Din server står bag en router, du ikke kan konfigurere, så den oplagte plan om at videresende en port er ikke mulig. VPN Azure findes netop til den situation, og det løser den ved at vende retningen af den første forbindelse: serveren ringer ud til et relæ, og klienter når relæet i stedet for serveren. Forståelsen af den vending forklarer både, hvad tjenesten løser, og enhver grænse, du senere vil ramme.

Hvad der ændres i vejen

Med en konventionel listener åbner en klient en TCP-forbindelse til en offentlig adresse, som din router videresender til serveren. Med relæet opretholder serveren en udgående forbindelse til relæinfrastrukturen, og relæet accepterer klientforbindelser og sender deres nyttelast videre til den ventende server. Der åbnes ingen indgående port, der kræves ingen statisk adresse, og routeren forbliver urørt. Set fra firewallens synspunkt er serveren en almindelig udgående klient, og det er derfor, restriktive netværk tillader den.

Relæet tildeler et navn på sit eget domæne til serveren, og klienter konfigureres til at forbinde dertil.

Det navn tilhører relætjenesten, som ikke er en Microsoft Azure VPN Gateway, selv om begge kaldes Azure noget. At behandle dem som udskiftelige giver en konfiguration, der ikke kan fungere.

Hvilke protokoller der overlever relæet

Relæet transporterer SoftEther-protokollen, og projektet dokumenterer SSTP som en klientmulighed, hvilket er nyttigt, fordi Windows leverer en SSTP-klient. Det bliver ikke en generel bærer for enhver listener på værten: en OpenVPN-listener, en IPsec-responder og en L2TP-tjeneste har hver brug for deres eget tilgængelige endepunkt, og ingen af dem transporteres gennem relæet, blot fordi SoftEther-serveren er forbundet.

Klientprofiler peger derfor på relænavnet i stedet for serveradressen, og en eksisterende profil bygget til en direkte forbindelse vil ikke fungere uændret. Tjek listen over understøttede klienter for den version, du kører, før du designer omkring en protokol, som relæet ikke bærer.

Hvad relæet ikke gør for dig

Relæet er en transport. Det opretter ikke brugere, virtuelle hubs, adgangspolitikker eller ruter, og det ved intet om de private netværk bag din server. Hvis fjernklienter skal nå et LAN-undernet, har serveren stadig brug for bro- eller routingkonfigurationen, returvejen og firewallpolitikken, der får det til at virke. Overlappende adresseplaner i de to ender er også usynlige for relæet og forbliver dit problem at løse.

De understøttede sikkerhedsindstillinger er også dine at vælge. Projektdokumentationen indeholder ældre platformseksempler, og at kopiere ældre cipher- eller certifikatindstillinger fra et gammelt skærmbillede er en god måde at bygge en tunnel, som ingen kan revidere. Brug den aktuelle vejledning til den version, du kører.

Certifikatvalidering og brugerautentificering forbliver serverens ansvar, og relæet erstatter aldrig nogen af dem.

Driv det som en afhængighed

Tilgængeligheden omfatter nu en tredjepart. Når relæet ikke kan nås, kan klienter ikke forbinde, uanset hvor sund din server er, og fejlen ser ud som et klientproblem udefra. Overvåg relævejen separat fra serverens egen sundhed, og hold en dokumenteret fallback som en direkte listener på en anden adresse til den dag, det betyder noget.

Latens følger relæets geografi frem for dine brugeres nærhed, hvilket er værd at måle, før du lover interaktiv ydeevne over det.

Bekræft serverens identitet og derefter en rigtig applikationsvej, ikke bare et vellykket forbindelsesbanner, og kontroller, om den ressource, du har brug for, kan nås over den adressefamilie, relæet bærer. Notér relænavnet, den anvendte protokol og fallbacken, fordi de tre fakta besvarer de fleste fremtidige spørgsmål om dette link.