SoftEther VPN Azure: releointireitti, ei avoin portti

Palvelimesi on sellaisen reitittimen takana, jota et voi määrittää, joten ilmeinen suunnitelma portin edelleenohjaamisesta ei ole käytettävissä. VPN Azure on olemassa juuri tätä tilannetta varten, ja se ratkaisee sen kääntämällä ensimmäisen yhteyden suunnan: palvelin soittaa ulos releelle, ja asiakkaat tavoittavat releen palvelimen sijaan. Tämän käännöksen ymmärtäminen selittää sekä sen, mitä palvelu korjaa, että jokaisen rajan, johon myöhemmin törmäät.

Mikä reitillä muuttuu

Perinteisellä kuuntelijalla asiakas avaa TCP-yhteyden julkiseen osoitteeseen, jonka reitittimesi välittää palvelimelle. Releen kanssa palvelin pitää yllä lähtevää yhteyttä releen infrastruktuuriin, ja rele ottaa vastaan asiakasyhteydet ja välittää niiden hyötykuorman odottavalle palvelimelle. Sisääntulevaa porttia ei avata, staattista osoitetta ei vaadita, ja reititin pysyy koskemattomana. Palomuurin näkökulmasta palvelin on tavallinen lähtevä asiakas, minkä vuoksi rajoittavat verkot sallivat sen.

Rele antaa kyseiselle palvelimelle nimen omassa verkkotunnuksessaan, ja asiakkaat määritetään yhdistämään sinne.

Nimi kuuluu relepalvelulle, joka ei ole Microsoft Azure VPN Gateway, vaikka kumpaakin kutsutaan Azure joksikin. Niiden pitäminen vaihdettavina tuottaa määrityksen, joka ei voi toimia.

Mitkä protokollat selviävät releestä

Rele kuljettaa SoftEther-protokollaa, ja projekti dokumentoi SSTP asiakasvaihtoehtona, mikä on hyödyllistä, koska Windowsissa on mukana SSTP-asiakas. Siitä ei kuitenkaan tule yleistä kuljettajaa isännän jokaiselle kuuntelijalle: OpenVPN-kuuntelija, IPsec-vastaaja ja L2TP-palvelu tarvitsevat kukin oman tavoitettavan päätepisteensä, eikä mitään niistä kuljeteta releen kautta vain siksi, että SoftEther-palvelin on yhdistetty.

Asiakasprofiilit osoittavat siksi releen nimeen palvelimen osoitteen sijaan, eikä suoraa yhteyttä varten rakennettu profiili toimi muuttamatta. Tarkista tuettujen asiakkaiden luettelo käyttämällesi versiolle ennen kuin suunnittelet protokollan varaan, jota rele ei kuljeta.

Mitä rele ei tee puolestasi

Rele on kuljetus. Se ei luo käyttäjiä, virtuaalisia hubeja, käyttöoikeuskäytäntöjä tai reittejä, eikä se tiedä mitään palvelimesi takana olevista yksityisverkoista. Jos etäasiakkaiden on päästävä LAN-aliverkkoon, palvelin tarvitsee edelleen silta- tai reititysmäärityksen, paluureitin ja palomuurikäytännön, jotka saavat sen toimimaan. Molempien päiden päällekkäiset osoitesuunnitelmat ovat myös releelle näkymättömiä ja jäävät sinun ratkaistavaksesi.

Myös tuetut suoja-asetukset ovat sinun valittavissasi. Projektin dokumentaatio sisältää vanhempien alustojen esimerkkejä, ja vanhentuneiden salakirjoitus- tai varmenneasetusten kopioiminen vanhasta kuvakaappauksesta on hyvä tapa rakentaa tunneli, jota kukaan ei voi auditoida. Käytä ajantasaista ohjetta käyttämällesi versiolle.

Varmenteiden vahvistus ja käyttäjien todennus pysyvät palvelimen vastuulla, eikä rele koskaan korvaa kumpaakaan.

Käytä sitä riippuvuutena

Saatavuus sisältää nyt kolmannen osapuolen. Kun rele ei ole tavoitettavissa, asiakkaat eivät voi yhdistää riippumatta siitä, kuinka terve palvelimesi on, ja vika näyttää ulkopuolelta asiakasongelmalta. Seuraa releen reittiä erikseen palvelimen omasta kunnosta ja pidä dokumentoitu varasuunnitelma, kuten suora kuuntelija toisessa osoitteessa, sitä päivää varten, jolloin sillä on merkitystä.

Viive noudattaa releen maantiedettä eikä käyttäjiesi läheisyyttä, ja se kannattaa mitata ennen kuin lupaat sen yli interaktiivista suorituskykyä.

Vahvista palvelimen identiteetti ja sitten todellinen sovelluspolku, ei vain onnistunutta yhteysbanneria, ja tarkista, onko tarvitsemasi resurssi tavoitettavissa sen osoiteperheen kautta, jota rele kuljettaa. Kirjaa releen nimi, käytetty protokolla ja varasuunnitelma, koska nämä kolme tosiasiaa vastaavat useimpiin tuleviin kysymyksiin tästä yhteydestä.