RRAS Azure VM netiek atbalstīts: pārbaudiet pirms projektēšanas

Jūs atverat portālu, izvietojat Windows Server 2022 apakštīklā, un Remote Access loma instalējas bez problēmām. Šī secība pierāda, ka instalētājs darbojas, nevis to, ka Microsoft atbalsta šo konfigurāciju. Publicētās serveru programmatūras atbalsta norādnes Azure virtuālajām mašīnām iekļauj RRAS starp Windows Server funkcijām, kas netiek atbalstītas Azure VM, un tas ir arhitektūras lēmums, nevis problēmu novēršanas detaļa. Tunelis, kas paceļas, nepārvieto izvietojumu atbalsta robežas iekšpusē.

Zemāk esošā rokasgrāmata sākas atbalsta lapā un pēc tam virzās uz prasībām un aizstāšanas iespējām.

Sāciet atbalsta lapā, nevis laboratorijā

Pirms kaut ko izmērīt, izlasiet Azure VM atbalsta norādnes. Tās atdala atbalstītos produktus, lomas un funkcijas, tā vietā lai Windows Server uzskatītu par vienu nediferencētu bloku. Ievērojiet, kurā rindā patiešām ietilpst jūsu paredzētā darba slodze, jo divi konsolē saistīti izskatoši komponenti var atrasties dažādās rindās.

Ierakstiet citātu projektēšanas dokumentā, kamēr lapa ir atvērta. Atbalsta statuss ir fakts ar avotu, un projektēšanas pārskatu, kas to nevar citēt, uzvarēs tas, kuram ir demonstrācija.

Atdaliet OS atbalstu no lomu un funkciju atbalsta

Tās pašas norādnes iekļauj Network Policy and Access Services atbalstīto lomu vidū, vienlaikus uzskaitot RRAS atsevišķi kā neatbalstītu. Šie divi ieraksti apraksta dažādas lietas, un to apvienošana formulējumā „attālināta piekļuve tiek atbalstīta“ ir veids, kā projekts tiek apstiprināts, pamatojoties uz nepareizu nolasījumu. Tas, ka operētājsistēma tiek atbalstīta, neko nepasaka par funkciju, kurai ir sava rinda.

Ierobežojums ir arī šaurāks, nekā to dažkārt citē. Tas attiecas uz šo funkciju, kas darbojas Azure VM iekšpusē; tas nenozīmē, ka privāts tīkls nevar savienoties ar Azure, un tas neapgalvo, ka RRAS netiek atbalstīts visur. Vecāka laboratorija, kas pareizi pārsūta paketes, ir pierādījums par paketēm, nevis par atbalsta paziņojumu.

Turiet šos divus jautājumus atsevišķi visu atlikušo projektu: vai tas darbojas, un vai tas tiek atbalstīts. Jums būs vajadzīgas dažādas atbildes un dažkārt dažādi atbildīgie par katru.

Pierakstiet, kas projektam patiešām jādara

Pirms aizstājēja izvēles pārvērtiet vietņu sarakstu prasībās, pēc kurām produktu var izmērīt:

• Tuneļa protokoli, kurus filiāļu ierīces jau izmanto, un vai kādai vietnei nepieciešama dinamiska maršrutēšana.
• Attālinātie prefiksi, tostarp jebkura pārklājošā adrešu telpa, kurai nepieciešama tulkošana, nevis maršrutēšana.
• Maršrutu apmaiņa ar Azure, un kam pieder katrs maršrutēšanas tabulas ieraksts.
• Caurlaidspēja un savienojumu skaits, kas jāiztur noslogotākajai stundai.
• Failover uzvedība, par ko vienojušies vietņu īpašnieki, nevis tikai tas, ko jūs varat uzbūvēt.

NAT ir vienums, kas tiek izlaists un pēc tam nosaka visu projektu. Ierīce, kas spēj izveidot IPsec, joprojām var tulkot adreses citādi nekā RRAS izvietojums, ko tā aizstāj, un tas maina, ko filiāle redz kā avota adreses un ko ieraksta jūsu žurnāli.

Aiznesiet sarakstu tīkla īpašniekiem un apstipriniet to pirms jebkādas produktu apspriešanas. Neskaidras prasības pārvērš katru piegādātāju salīdzinājumu gaumes strīdā.

Novērtējiet aizstājējus pret šīm prasībām

Azure pārvaldītie savienojamības pakalpojumi un piegādātāju atbalstītās tīkla virtuālās ierīces abi jāvērtē pret to pašu sarakstu. Nepieņemiet, ka kāds no tiem ir tiešs RRAS VM ekvivalents tikai tāpēc, ka tas spēj pabeigt IPsec: NAT modelis un maršrutu īpašumtiesības un augstas pieejamības projektējums nosaka, kā savienojas esošās vietnes un kur atgriežas to atbildes. Novērtējiet katru kandidātu uz papīra pret sarakstu un pierakstiet, kuras prasības tas neizpilda, jo tieši šī piezīme padara izvēli vēlāk pārskatāmu.

Slodzes balansētājs divu ierīču VM priekšā pats par sevi nav augsta pieejamība. Tas nodrošina priekšgalu, nevis sinhronizētu tuneļa stāvokli, un pāreja, kas nomet katru sesiju, ir projektēšanas lēmums, kas kādam jāpieņem apzināti. Jautājiet ierīces piegādātājam, kāds ir atbalstītais HA modelis un vai tas atbilst vietnēm solītajai pieejamībai. Pārbaudiet pāreju pirms tam, kad šīs vietnes kļūst no tās atkarīgas, un katru zaudēto sesiju uzskatiet par atradumu, nevis pārsteigumu.

Kur prasība patiešām ir vienkārša — viena vietne, viens prefikss, nav pārklāšanās — pārvaldīts pakalpojums parasti uzvar ekspluatācijas izmaksās. Kur tulkošana un dinamiskā maršrutēšana abas ir spēlē, ierīces ceļš var būt vienīgais piemērotais, un tas ir iemesls plānot garāku migrāciju, nevis paturēt neatbalstīto VM.

Ja RRAS VM jau darbojas

Atklāšana nav iemesls to dzēst. Plānojiet izmaiņas ap atkarībām, ko šī VM ir uzkrājusi: maršrutiem, uz kuriem paļaujas citi apakštīkli, NAT noteikumiem, kas slēpj avota adreses, un visu, ko uzraudzība ir iemācījusies gaidīt no tās adreses. Saglabājiet nepieciešamos maršrutus un pārbaudītu atkopšanas ceļu, kamēr atbalstītais mērķis tiek projektēts un validēts līdzās.

Visu laiku turiet atbalstāmību un tehnisko diagnostiku kā atsevišķus atradumus. Neatbalstītam izkārtojumam var būt arī parasta maršrutēšanas kļūda, un šīs kļūdas labošana nemaina tā atbalsta statusu. Abi apgalvojumi pieder pie ziņojuma, un neviens neatsauc otru.

Noslēdziet rokasgrāmatu, ierakstot atbalsta citātu, prasību sarakstu, izvēlēto aizstājēju un pārejas secību. Šie četri punkti ir pirmie, ko jautās auditors vai jauns komandas loceklis.