RRAS Azure-VM:ssä ei ole tuettu: tarkista ennen suunnittelua

Avaat portaalin, otat Windows Server 2022:n käyttöön aliverkossa ja Remote Access -rooli asentuu puhtaasti. Tämä järjestys todistaa, että asentaja toimii, ei sitä että Microsoft tukee kokoonpanoa. Julkaistu palvelinohjelmiston tukiohje Azure-virtuaalikoneille listaa RRAS:n niiden Windows Server -ominaisuuksien joukkoon, joita ei tueta Azure-VM:issä, ja se on arkkitehtuuripäätös, ei vianetsinnän yksityiskohta. Ylös nouseva tunneli ei siirrä käyttöönottoa tuen rajan sisään.

Alla oleva läpikäynti alkaa tukisivulta ja etenee siitä vaatimuksiin ja korvausvaihtoehtoihin.

Aloita tukisivulta, älä laboratoriosta

Lue Azure-VM:n tukiohje ennen kuin mitoitat mitään. Se erottelee tuetut tuotteet, roolit ja ominaisuudet sen sijaan, että kohtelisi Windows Serveriä yhtenä eriyttämättömänä lohkona. Huomaa, mihin riviin aiottu työkuormasi todella kuuluu, sillä kaksi konsolissa sukulaisselta näyttävää komponenttia voi olla eri riveillä.

Kirjoita viittaus suunnitteludokumenttiin, kun sivu on auki. Tukitila on tosiasia, jolla on lähde, ja suunnittelukatselmus, joka ei voi viitata siihen, häviää sille, jolla on demo.

Erottele käyttöjärjestelmän tuki roolien ja ominaisuuksien tuesta

Samat ohjeet listaavat Network Policy and Access Servicesin tuettujen roolien joukkoon, kun taas RRAS listataan erikseen tukemattomaksi. Nämä kaksi merkintää kuvaavat eri asioita, ja niiden yhdistäminen muotoon „etäkäyttöä tuetaan“ on se tapa, jolla projekti hyväksytään väärän luennan perusteella. Käyttöjärjestelmän tukeminen ei kerro mitään ominaisuudesta, jolla on oma rivinsä.

Rajoitus on myös kapeampi kuin sitä joskus siteerataan. Se koskee tätä ominaisuutta Azure-VM:n sisällä; se ei tarkoita, ettei yksityisverkko voi yhdistää Azureen, eikä se sano, ettei RRAS ole tuettu kaikkialla. Vanhempi laboratorio, joka välittää paketteja oikein, on todiste paketeista, ei tukilausumasta.

Pidä nämä kaksi kysymystä erillään loppuprojektin ajan: toimiiko se ja tuetaanko sitä. Tarvitset eri vastaukset ja joskus eri omistajat kummallekin.

Kirjoita, mitä suunnittelun on todella tehtävä

Ennen korvaavan ratkaisun valintaa muunna sivustoluettelo vaatimuksiksi, joita vasten tuotetta voidaan mitata:

• Tunneliprotokollat, joita haarakonttorien laitteet jo puhuvat, ja tarvitseeko jokin sivusto dynaamista reititystä.
• Etäprefiksit, mukaan lukien mahdollinen päällekkäinen osoiteavaruus, joka vaatii käännöstä eikä reititystä.
• Reittien vaihto Azuren kanssa ja se, kuka omistaa kunkin reititystaulun merkinnän.
• Läpäisykyky ja yhteyksien määrä, jotka kiireisimmän tunnin on kestettävä.
• Sivustojen omistajien sopima vikasietokäyttäytyminen, ei vain se, minkä voit rakentaa.

NAT on kohta, joka ohitetaan ja joka sitten ratkaisee koko suunnittelun. Laite, joka pystyy muodostamaan IPsecin, voi silti kääntää osoitteita eri tavalla kuin korvaamansa RRAS-käyttöönotto, mikä muuttaa sitä, mitä haara näkee lähdeosoitteina ja mitä lokisi tallentavat.

Vie luettelo verkon omistajille ja vahvista se ennen mitään tuotekeskustelua. Epäselvät vaatimukset tekevät jokaisesta toimittajavertailusta mieltymyskiistan.

Arvioi korvaavat ratkaisut näitä vaatimuksia vasten

Azuren hallinnoimat yhteydenpitopalvelut ja toimittajien tukemat verkon virtuaalilaitteet on molemmat pisteytettävä samaa luetteloa vasten. Älä oleta, että kumpikaan on suora vastine RRAS-VM:lle vain siksi, että se pystyy päättämään IPsecin: NAT-malli ja reittien omistajuus sekä korkean käytettävyyden suunnittelu ratkaisevat, miten olemassa olevat sivustot yhdistyvät ja minne niiden vastaukset palaavat. Pisteytä jokainen ehdokas paperilla luetteloa vasten ja kirjoita, mitkä vaatimukset se jättää täyttämättä, sillä juuri se muistiinpano tekee valinnasta myöhemmin tarkistettavan.

Kuormantasain kahden laite-VM:n edessä ei ole itsessään korkea käytettävyys. Se tarjoaa front endin, ei synkronoitua tunnelitilaa, ja vikasieto, joka pudottaa jokaisen istunnon, on suunnittelupäätös, jonka jonkun on tehtävä tarkoituksella. Kysy laitteen toimittajalta, mikä on tuettu HA-malli ja vastaako se sivustoille luvattua käytettävyyttä. Testaa vikasieto ennen kuin nämä sivustot ovat siitä riippuvaisia, ja kohtele jokaista menetettyä istuntoa löydöksenä, ei yllätyksenä.

Kun vaatimus on aidosti yksinkertainen — yksi sivusto, yksi prefiksi, ei päällekkäisyyttä — hallinnoitu palvelu voittaa yleensä käyttökustannuksissa. Kun käännös ja dynaaminen reititys ovat molemmat pelissä, laitepolku voi olla ainoa sopiva, ja se on syy suunnitella pidempi migraatio sen sijaan, että pitäisi tuen ulkopuolisen VM:n.

Jos RRAS-VM on jo käynnissä

Löytäminen ei ole syy poistaa sitä. Suunnittele muutos sen VM:n keräämien riippuvuuksien ympärille: reitit, joihin muut aliverkot luottavat, lähdeosoitteet piilottavat NAT-säännöt ja kaikki se, mitä valvonta on oppinut odottamaan sen osoitteelta. Säilytä tarvittavat reitit ja testattu palautumispolku, kun tuettu tavoite suunnitellaan ja validoidaan rinnalla.

Pidä tuettavuus ja tekninen diagnoosi erillisinä löydöksinä koko ajan. Tukemattomassa järjestelyssä voi olla myös tavallinen reititysvirhe, eikä sen virheen korjaaminen muuta sen tukitilaa. Molemmat väitteet kuuluvat raporttiin, eikä kumpikaan kumoa toista.

Päätä läpikäynti kirjaamalla tukiviittaus, vaatimusluettelo, valittu korvaava ratkaisu ja siirtymäjärjestys. Nämä neljä kohtaa ovat ensimmäiset, joita auditoija tai uusi tiimin jäsen kysyy.