Azure P2S -DNS epäonnistuu, kun resolver on peeratussa VNetissä

Pingaa VM ja se vastaa; kysy sen nimeä ja asiakas sanoo, että isäntä on tuntematon. Kun resolver on peeratussa virtuaaliverkossa eikä siinä, joka sisältää VPN-gatewayn, tämä tulos pari on odotettavissa, eikä mikään määrä resolverin vianetsintää muuta sitä. Puuttuu reitityssopimus, jonka peering pidättää oletuksena. Kaksi topologiaa näyttävät paperilla lähes identtisiltä, ja ero toimivan ja rikkinäisen välillä on oikeaan suuntaan asetettu peering-kytkinpari.

Kuvittele kannettava tietokone, joka tunneloi VNet2:n gatewayhin, kun taas DNS:ää palveleva toimialueen ohjauskone istuu VNet1:ssä.

Kaksi topologiaa, yksi ero

Laita resolver gatewayn omaan virtuaaliverkkoon, ja nimi ratkeaa heti, kun tunneli nousee. Mikään peering-asetus ei osallistu tuohon hakuun.

Siirrä sama resolver peeringin toiselle puolelle, ja asiakas saa yhä vastauksen VM:ltä, kun nimi pysyy tuntemattomana. Varmenne, tunneli ja asiakas ovat ennallaan. Ainoa, mikä siirtyi, on se, missä resolver asuu. Peering antoi sille reitin tuohon osoitteeseen, ei gatewaylle valtuutta kuljettaa liikennettä sinne.

Puoli A: salli gatewayn transitio gatewayn omistajalla

Peering yhdistää kaksi virtuaaliverkkoa, mutta yhdistys ei ole transitiivinen liikenteelle, joka saapuu gatewayn kautta, ja point-to-site-pyyntö saapuu juuri niin. Siksi VNet2:n gatewaylla ei ole valtuutta luovuttaa hakua VNet1:lle ennen kuin suunnittelu sen sallii. Lupa on kytkin peeringissä, jonka omistaa gatewayn sisältävä verkko.

Aseta Allow gateway transit VNet2:n peeringiin kohti VNet1:tä. Ominaisuus kuuluu peering-objektille, ei gateway-resurssille, joten luet ja muutat sitä peering-terässä. Siinä on koko puoli A.

Puoli B: käytä etä-gatewayta peerissä

Toinen puoli on peilikuva: aseta VNet1:n peeringissä takaisin VNet2:een päälle Use remote gateways. Saman lipun kytkeminen molemmissa päissä tai vain toisessa jättää puoliksi rakennetun polun ja alkuperäisen oireen ennalleen. Vain verkko, jossa on VPN-gateway, sallii transitiön, ja peer on se puoli, joka sitä käyttää.

Lue molemmat ominaisuudet molemmista verkoista sen sijaan, että luottaisit viimeksi avaamaasi portaalin terään.

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

Parin näkeminen rinnakkain on nopein tapa napata käännetty asetus. Peering, joka ilmoittaa gatewayn puolella AllowGatewayTransit false, selittää koko vian ilman paketin sieppausta.

Mitä asiakkaan on vielä saatava

Reititys on välttämätöntä mutta ei riittävää, koska point-to-site-profiilin on myös annettava asiakkaalle DNS-osoite, joka vastaa, kun transitio toimii. Alustan resolver ei ole se osoite: se vastaa virtuaaliverkkoon liitetyistä Azure Private DNS -vyöhykkeistä, mutta ei vyöhykkeestä, joka on isännöity omilla hakemistopalvelimillasi, ja juuri sitä tämä käyttöönotto käyttää. Osoita asiakas siihen, ja julkiset nimet ratkeavat iloisesti, kun sisäinen isäntä pysyy tuntemattomana.

Kysy resolverilta yhdistetystä kannettavasta ennen kuin muutat mitään muuta.

nslookup dc01.corp.example 10.1.0.4

Aikakatkaisu kertoo, että polku puuttuu yhä. Valtuutettu vastaus työntää ongelman takaisin asiakkaalle, yleensä suffiksi, jota ei koskaan liitetä, joten lyhyet nimet matkaavat julkiselle resolverille, joka epäonnistuu ne iloisesti.

Vertaa samaa sopimusta site-to-site-puolella

Mikään tästä ei kuulu erityisesti kannettaville. Vaihda asiakas site-to-site-sivukonttoriin, ja kaksipuolinen vaatimus palaa: sivukonttori saapuu suoraan gateway-verkkoon, ja palvelu kahden verkon päässä on yhä peeringin takana.

Transitio on myönnettävä molemmissa peeringeissä, ja kytkin, joka sen myöntää, elää peeringissä eikä asiakastyypissä.

Ennen kuin syytät gatewayta

Windows pitää resolverilistaa sovitinkohtaisesti, joten varmista, mitä tunneliliitäntä todella sai, ennen kuin syytät gatewayta.

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

Kielteinen vastaus elää välimuistissa reitityskorjausta pidempään, ja vanhentunut suffiksilista lähettää kyselyitä edelleen paikkaan, joka ei koskaan isännöinyt vyöhykettä. Tyhjennä, kysy uudelleen ja kirjaa, mikä palvelin vastaa.

Kaksi pienempää ehtoa ratkaisee, pysyykö polku: osoiteavaruuksien ei pidä mennä päällekkäin, ja resolverin aliverkon verkkoturvaryhmän on päästettävä asiakaspooli läpi, mikä on vain yksi lähdealue lisää. Todista se VM:n puolelta tehtävällä tehokkaan reitin tarkistuksella sekä yhdellä suoralla kyselyllä asiakkaalta, jotta vyöhykeongelmaa, suffiksiongelmaa tai suodatinta ei koskaan sekoiteta puuttuvaan transitioon.