Egin ping VMari eta erantzun egiten du; galdetu bere izena eta bezeroak dio ostalaria ezezaguna dela. Resolverra VPN atea duen sarean egon beharrean parekatutako sare birtualean dagoenean, emaitza bikote hori espero daiteke, eta resolverraren arazketa-kopuruak ez du hori aldatzen. Faltan dagoena parekatzeak lehenespenez atxikitzen duen bideratze-kontratua da. Bi topologia ia berdinak dira paperean, eta funtzionatzen duenaren eta apurtuaren arteko aldea norabide egokian jarritako parekatze-etengailu pare bat da.

Imajinatu ordenagailu eramangarri bat VNet2ko ate batera tunelatzen, DNS zerbitzatzen duen domeinu-kontrolatzailea VNet1ean dagoelarik.

Bi topologia, diferentzia bat

Jarri resolverra atearen bere sare birtualean eta izena tunela altxatzen den unean ebatziko da. Parekatze-ezarpen batek ere ez du bilaketa horretan parte hartzen.

Eraman resolver bera parekatze baten beste aldera eta bezeroak oraindik VMaren erantzuna jasotzen du izena ezezaguna izaten jarraitzen duen bitartean. Ziurtagiria, tunela eta bezeroa ez dira aldatu. Aldatu den gauza bakarra resolverra non bizi den da. Parekatzeak helbide horretarako bidea eman zion, ez ateak han trafikoa eramateko aginpidea.

A aldea: baimendu atearen transitioa atearen jabean

Parekatzeak bi sare birtual lotzen ditu, baina lotura ez da iragankorra ate batetik iristen den trafikoarentzat, eta puntutik gunera egindako eskaera hain zuzen horrela iristen da. Beraz, VNet2ko ateak ez du bilaketa VNet1i emateko gaitasunik diseinuak baimena eman arte. Baimena atearen jabe den sareak dituen parekatzean dagoen etengailua da.

Ezarri Allow gateway transit VNet2tik VNet1erako parekatzean. Propietatea parekatze objektuarena da, ez atearen baliabidearena, beraz parekatze-orrian irakurri eta aldatzen da. Hori da A aldea osoa.

B aldea: erabili urruneko ateak bikotean

Beste erdia ispilu-irudia da: VNet1etik VNet2rako parekatzean, gaitu Use remote gateways. Bandera bera bi muturretan edo batean soilik aktibatzeak erdi egindako bidea eta jatorrizko sintoma ukitugabe uzten ditu. VPN atea duen sareak bakarrik onartzen du transitioa, eta bikotea hori erabiltzen duen aldea da.

Irakurri bi propietateak bi sareetan, azken aldiz irekitako atari-orrian fidatu beharrean.

Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet2 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways
Get-AzVirtualNetworkPeering -ResourceGroupName rg-core -VirtualNetworkName vnet1 `
  | Format-List Name,AllowGatewayTransit,UseRemoteGateways

Bikotea elkarren ondoan ikustea ezarpen alderantzikatua harrapatzeko modurik azkarrena da. Atearen aldean AllowGatewayTransit false ematen duen parekatze batek huts egite osoa azaltzen du pakete-kapturarik gabe.

Zer jaso behar du oraindik bezeroak

Bideratzea beharrezkoa da eta ez da nahikoa, puntutik gunera profilak bezeroari transitioa funtzionatzen duenean erantzuten duen DNS helbidea eman behar diolako. Plataformaren resolverra ez da helbide hori: sare birtualari lotutako Azure Private DNS eremuei erantzuten die, baina ez zerorrek zure direktorio-zerbitzarietan ostatatutako eremu bati, eta horixe erabiltzen du hedapen honek. Seinalatu bezero bat horri eta izen publikoak pozik ebatziko dira, barneko ostalaria ezezaguna izaten jarraitzen duen bitartean.

Galdetu resolverrari konektatutako ordenagailu eramangarritik, beste ezer aldatu aurretik.

nslookup dc01.corp.example 10.1.0.4

Denbora-muga batek dio bidea oraindik falta dela. Erantzun autoritatiboak arazoa bezeroarengana bultzatzen du, normalean inoiz eransten ez den atzizki bat, beraz izen laburrak pozik huts egiten duen resolver publiko batera joaten dira.

Konparatu kontratu bera gunez guneko aldean

Hauetako ezer ez da berez ordenagailu eramangarriena. Ordeztu bezeroa gunez guneko sukurtsal batekin eta bi aldetako baldintza itzultzen da: sukurtsala zuzen iristen da aterainoko sarera, eta bi sare distantziara dagoen zerbitzu bat parekatzearen atzean dago oraindik.

Transitioa bi parekatzeetan eman behar da, eta hura ematen duen etengailua parekatzean bizi da, ez bezero motan.

Atea erruduntzat jo aurretik

Windowsek resolver-zerrenda gordetzen du egokitzaile bakoitzeko, beraz egiaztatu tunel-interfazeak benetan zer jaso zuen atearen errua bota aurretik.

ipconfig /all
Get-DnsClientServerAddress -AddressFamily IPv4
ipconfig /flushdns

Erantzun negatiboak bideratze-konponketa baino gehiago irauten du cachean, eta atzizki-zerrenda zaharkituak galderei bidaltzen jarraitzen die eremua inoiz ostatatu ez zuen tokira. Garbitu, galdetu berriro, eta idatzi zein zerbitzarik erantzuten duen.

Bi baldintza txikiagok erabakitzen dute bideak eusten ote duen: helbide-espazioek ez dute gainjarri behar, eta resolverraren azpisareko sare-segurtasun-taldeak bezeroen poolari utzi behar dio, beste iturburu-barruti bat besterik ez dena. Frogatu VMaren aldetik bide eraginkorren egiaztapen batekin eta bezeroaren kontsulta zuzen batekin, eremu-arazo bat, atzizki-arazo bat edo iragazki bat inoiz falta den transitioarekin nahas ez daitezen.

Erlazionatutako artikuluak