SoftEther VPN Azure: ’n Relaisroete, nie ’n oop poort nie

Jou bediener sit agter ’n router wat jy nie kan opstel nie, so die ooglopende plan om ’n poort deur te stuur is onbeskikbaar. VPN Azure bestaan juis vir daardie situasie, en dit los dit op deur die rigting van die eerste verbinding om te keer: die bediener bel uit na ’n relais, en kliënte bereik die relais eerder as die bediener. Om daardie omskepping te verstaan verduidelik beide wat die diens regstel en elke beperking wat jy later sal teëkom.

Wat in die roete verander

Met ’n gewone luisteraar maak ’n kliënt ’n TCP-verbinding oop na ’n publieke adres wat jou router na die bediener deurstuur. Met die relais hou die bediener ’n uitwaartse verbinding na die relaisinfrastruktuur in stand, en die relais aanvaar kliëntverbindings en gee hul vrag aan die wagtende bediener deur. Geen inkomende poort word oopgemaak nie, geen statiese adres word vereis nie, en die router bly onaangeraak. Vanuit die firewall se oogpunt is die bediener ’n gewone uitwaartse kliënt, en daarom laat beperkende netwerke dit toe.

Die relais ken ’n naam op sy eie domein aan daardie bediener toe, en kliënte word opgestel om daarheen te verbind.

Daardie naam behoort aan die relaisdiens, wat nie ’n Microsoft Azure VPN Gateway is nie, al word albei Azure-iets genoem. Om hulle as uitruilbaar te behandel lewer ’n opstelling op wat nie kan werk nie.

Watter protokolle die relais oorleef

Die relais vervoer die SoftEther-protokol, en die projek dokumenteer SSTP as ’n kliëntopsie, wat nuttig is omdat Windows ’n SSTP-kliënt saamstuur. Dit word nie ’n algemene draer vir elke luisteraar op die gasheer nie: ’n OpenVPN-luisteraar, ’n IPsec-responder en ’n L2TP-diens het elkeen hul eie bereikbare eindpunt nodig, en nie een word deur die relais vervoer bloot omdat die SoftEther-bediener gekoppel is nie.

Kliëntprofiele wys dus na die relaisnaam eerder as na die bedieneradres, en ’n bestaande profiel wat vir ’n direkte verbinding gebou is, sal nie onveranderd werk nie. Kyk na die ondersteunde kliëntlys vir die weergawe wat jy gebruik voordat jy rondom ’n protokol beplan wat die relais nie dra nie.

Wat die relais nie vir jou doen nie

Die relais is ’n vervoermiddel. Dit skep nie gebruikers, virtuele hubs, toegangsbeleide of roetes nie, en dit weet niks van die private netwerke agter jou bediener nie. As afgeleë kliënte ’n LAN-subnet moet bereik, het die bediener steeds die oorbruggings- of routeringsopstelling, die terugpad en die firewallbeleid nodig wat dit laat werk. Oorvleuelende adresplanne aan die twee kante is ook onsigbaar vir die relais en bly jou probleem om op te los.

Ondersteunde sekuriteitsinstellings is ook joune om te kies. Die projekdokumentasie bevat ouer platformvoorbeelde, en om legacy-syfer- of sertifikaatinstellings uit ’n ou skermbeeld te kopieer is ’n goeie manier om ’n tonnel te bou wat niemand kan oudit nie. Gebruik huidige leiding vir die weergawe wat jy gebruik.

Sertifikaatvalidering en gebruikerverifikasie bly die bediener se verantwoordelikheid, en die relais vervang nooit een van die twee nie.

Bedryf dit as ’n afhanklikheid

Beskikbaarheid sluit nou ’n derde party in. Wanneer die relais onbereikbaar is, kan kliënte nie verbind nie, ongeag hoe gesond jou bediener is, en die fout lyk van buite soos ’n kliëntprobleem. Monitor die relaisroete apart van die bediener se eie gesondheid, en hou ’n gedokumenteerde terugval soos ’n direkte luisteraar op ’n ander adres gereed vir die dag wanneer dit saak maak.

Latensie volg die relais se geografie eerder as jou gebruikers se nabyheid, wat die moeite werd is om te meet voordat jy interaktiewe werkverrigting daaroor belowe.

Verifieer die bediener se identiteit en dan ’n werklike toepassingsroete, nie net ’n suksesvolle verbindingsbanier nie, en kyk of die hulpbron wat jy nodig het bereikbaar is oor die adresfamilie wat die relais dra. Teken die relaisnaam, die protokol wat gebruik word en die terugval aan, want daardie drie feite beantwoord die meeste toekomstige vrae oor hierdie skakel.