SoftEther VPN Azure: in relaisrûte, gjin iepen poarte

Jo tsjinner stiet efter in router dy’t jo net konfigurearje kinne, dus it foar de hân lizzende plan om in poarte troch te stjoeren is net beskikber. VPN Azure bestiet krekt foar dy situaasje, en it lost dy op troch de rjochting fan de earste ferbining om te kearen: de tsjinner skillet út nei in relais, en kliïnten berikke it relais ynstee fan de tsjinner. Begripen fan dy omkearing ferklearret sawol wat de tsjinst oplost as elke beheining dy’t jo letter tsjinkomme sille.

Wat der yn de rûte feroaret

By in gewoane listener iepenet in kliïnt in TCP-ferbining nei in iepenbier adres dat jo router nei de tsjinner trochstjoert. By it relais hâldt de tsjinner in útgong-ferbining nei de relaisynfrastruktuer yn stân, en it relais akseptearret kliïntferbinings en jout harren lading oan de wachtende tsjinner troch. Gjin yngeande poarte wurdt iepene, gjin statysk adres is nedich, en de router bliuwt ûnoanroerd. Fan it eachpunt fan ’e firewall is de tsjinner in gewoane útgong-kliïnt, en dêrom litte beheinende netwurken it ta.

It relais tawiist dy tsjinner in namme op syn eigen domein, en kliïnten wurde konfigurearre om dêrhinne te ferbinen.

Dy namme heart by de relastsjinst, dy’t gjin Microsoft Azure VPN Gateway is, al wurde se beide Azure-iets neamd. Se as útwikselber behannelje leveret in konfiguraasje op dy’t net wurkje kin.

Hokker protokollen it relais oerlibje

It relais ferfiert it SoftEther-protokol, en it projekt dokumentearret SSTP as in kliïntopsje, wat nuttich is om’t Windows in SSTP-kliïnt meistjoerdt. It wurdt lykwols gjin algemiene drager foar elke listener op ’e host: in OpenVPN-listener, in IPsec-antwurder en in L2TP-tsjinst hawwe elk har eigen berikbere einpunt nedich, en gjinien fan harren wurdt troch it relais ferfierd allinnich om’t de SoftEther-tsjinner ferbûn is.

Kliïntprofilen wize dêrom nei de relaisnamme ynstee fan nei it tsjinneradres, en in besteand profyl dat boud is foar in direkte ferbining sil net ûnferoare wurkje. Kontrolearje de list fan stipe kliïnten foar de ferzje dy’t jo draaie foardat jo om in protokol hinne ûntwerpe dat it relais net draacht.

Wat it relais net foar jo docht

It relais is in ferfier. It makket gjin brûkers, firtuele hubs, tagongspolissen as rûtes oan, en it wit neat fan de partikuliere netwurken efter jo tsjinner. As fiere kliïnten in LAN-subnet berikke moatte, hat de tsjinner noch hieltyd de brêge- of routingkonfiguraasje, it werompaad en it firewallbelied nedich dy’t dat wurkje litte. Oerlappende adresplannen oan beide einen binne ek ûnsichtber foar it relais en bliuwe jo probleem om op te lossen.

Ek de stipe feiligensynstellingen binne jo te kiezen. De projektdokumintaasje befettet foarbylden fan âldere platfoarms, en ferâldere syfer- as sertifikaatynstellingen fan in âlde skermôfdrukke kopiearje is in goede manier om in tunnel te bouwen dy’t nimmen auditearje kin. Brûk de aktuele lieding foar de ferzje dy’t jo draaie.

Sertifikaatfalidaasje en brûkersautentikaasje bliuwe ferantwurdlikheid fan ’e tsjinner, en it relais ferfangt nea ien fan beide.

Operearje it as in ôfhinklikens

Byskikberens omfettet no in tredde partij. As it relais net berikber is, kinne kliïnten net ferbine, hoe sûn jo tsjinner ek is, en de flater liket fan bûten op in kliïntprobleem. Monitoarje it relaispaad apart fan ’e sûnens fan ’e tsjinner, en hâld in dokumintearre weromfal lykas in direkte listener op in oar adres foar de dei dat it ta docht.

Latinsje folget de geografy fan it relais ynstee fan ’e neite fan jo brûkers, wat it wurdich is om te mjitten foardat jo ynteraktive prestaasjes dêroer tasizze.

Ferifiearje de identiteit fan ’e tsjinner en dan in echte applikaasjerûte, net allinnich in suksesfolle ferbiningsbanner, en kontrolearje oft de boarne dy’t jo nedich hawwe berikber is oer de adresfamylje dy’t it relais draacht. Skriuw de relaisnamme, it brûkte protokol en de weromfal op, want dy trije feiten beantwurdzje de measte takomstige fragen oer dizze keppeling.