Azure UDR VPN-yhdyskäytävälle: yksi kohde, ei koko lähtevä liikenne

Lisäät käyttäjän määrittämän reitin yhdelle ulkoiselle etuliitteelle, osoitat sen VPN-yhdyskäytävään, ja liikenne lähtee silti Azure'n internetpolkua. Tai se lähtee oikein eikä vastausta koskaan tule takaisin. Molemmat tulokset johtuvat samasta virheestä: Azure'n seuraavan hypyn pitämisestä koko suunnitelmana. Reittitaulukko päättää vain, mistä lähdöstä paketti poistuu Azure'n sisällä. Mitä sille tapahtuu tunnelin jälkeen ja miten vastaus palaa, on toinen puoli, joka sinun on rakennettava.

Seuraava hyppy on yhdyskäytävä, ei laitteen IP

UDR lähettää vastaavan etuliitteen seuraavan hypyn tyypille, ja VirtualNetworkGateway on tyyppi, ei osoite. Ihmiset liittävät yhdyskäytävän yksityisen IP:n VirtualAppliance-reittiin ja ihmettelevät sitten, miksei mikään täsmää, koska tämä tyyppi odottaa sen sijaan NIC:iä tai sisäistä kuormantasaajaa. Microsoftin reititysdokumentaatio rajaa myös yhdyskäytävän seuraavan hypyn virtuaaliverkkoon, jonka yhdyskäytävä on VPN-yhdyskäytävä. ExpressRoute, Route Server ja Virtual WAN -keskittämö eivät ole tämän vaihtoehdon osoitettavissa.

Tarkista, mitä virtuaaliverkossa todella on, ennen kuin kirjoitat reitin. Jos suunnitelma reitittää keskittämön kautta, reitti kuuluu keskittämön reitityksen omistajalle, ei sille spokelle, jota satut muokkaamaan.

Lue voimassa oleva reitti ennen kuin muutat mitään

Azure yhdistää järjestelmäreitit, BGP:n kautta opitut etuliitteet ja UDR:t tehokkaaksi reittitaulukoksi NIC-kohtaisesti, ja pisimpään täsmäävä etuliite voittaa riippumatta siitä, mistä se tuli. Samalle etuliitteelle UDR voittaa BGP-reitin. Tämä järjestys on syy siihen, miksi aiemmasta kokeesta jäänyt vanhentunut UDR voi hiljaa ohittaa etuliitteen, jonka juuri opit tunnelin kautta.

Katso ensin tehokasta taulukkoa ja päätä sitten, lisäätkö reitin vai korvaatko sellaisen:

az network nic show-effective-route-table \
  --resource-group rg-net --name vm-web-nic -o table

Lue myös lähdesarake, ei vain etuliite. Oikean etuliitteen ja väärän lähteen reitti kertoo, mitä objektia muokata, ja säästää sinut lisäämästä toista reittiä, joka häviää ensimmäiselle.

Kirjoita reitti todellisen etuliitteen ja aliverkon mukaan

Käytä kohteen todellista etuliitettä, otettuna palvelusta, johon todella pääset, sen sijaan että kopioisit julkisen alueen foorumiviestistä. Aloita yhdestä hyväksytystä palvelusta ennen kuin harkitset oletusreittiä, joka siirtää kaiken lähtevän liikenteen. Kiinnitä sitten reittitaulukko työkuorman aliverkkoon. Yhdyskäytävän aliverkolla on omat vaatimuksensa, ja taulukkosi kiinnittäminen sinne rikkoo yhdyskäytävän sen sijaan, että ohjaisi työkuormaa.

Luo reitti ja sido sitten taulukko aliverkkoon, jossa työkuorma on:

az network route-table route create --resource-group rg-net --route-table-name rt-egress \
  --name to-partner --address-prefix 203.0.113.0/24 --next-hop-type VirtualNetworkGateway
az network vnet subnet update --resource-group rg-net --vnet-name vnet-app \
  --name snet-web --route-table rt-egress

Myös levitys on tärkeää. Kun BGP-levitys on käytössä tässä taulukossa, opitut etuliitteet näkyvät kirjoittamiesi rinnalla, ja tarkempi opittu etuliite voi voittaa laajemman UDR:n. Poista levitys käytöstä vain, kun haluat UDR-joukon olevan määräävä kyseiselle aliverkolle.

Viimeistele paikallinen puoli tai virta kuolee siihen

Paikallisen yhdyskäytävän on hyväksyttävä Azure-lähde, välitettävä se kohteeseen ja sallittava sovellus. Sen jatkopolku voi olla internetlähtö tai toinen yksityinen hyppy, mutta se päätös kuuluu suunnitelmaan, ei Azure'n reittitaulukkoon. Tavallinen epäonnistuminen on paluu. Internet-kohde ei reititä yksityistä Azure-lähdettä takaisin sinulle, joten vastaus menee omaan oletusyhdyskäytäväänsä ja kuolee, tai ei lähde lainkaan.

Kaksi suunnitelmaa ratkaisee tämän, eivätkä ne ole vaihdettavissa. Käännä lähde lähdössä, jotta kohde vastaa julkiseen osoitteeseen, jonka paikallinen verkko omistaa. Tai säilytä lähde ja rakenna reititetty paluusuhde, jotta vastaukset palaavat tunnelin kautta. Valitse yksi ja kirjoita muistiin, minkä osoitteen sovellus näkee.

Valitsimet ja sallitut listat ovat erillään tästä kaikesta. Azure-seuraavan hypyn valinta ei laajenna VPN-liikenteen valitsimia eikä muuta ulkoisen palvelun lähdesallittua listaa.

Vahvista kohteen havaitsemalla lähteellä

Lähetä pyyntö todellisesta työkuormasta eikä hyppypalvelimelta toisessa aliverkossa ja lue sitten lähdeosoite, jonka kohde havaitsi. Tämä yksi arvo kertoo, kumpi kahdesta paluusuunnitelmasta on käytössä. Tarkista seuraavaksi vastauspolku ja varmista, että tavallinen hallintaliikenne VM:ään toimii edelleen, koska vahingossa lisätty oletusreitti näkyy katkenneena SSH-istuntona paljon ennen kuin se näkyy rikkinäisenä sovelluksena.

Valitun etuliitteen kautta kulkeva transit on paljon kapeampi muutos kuin pakotettu tunnelointi. Pidä se kapeana, jolloin peruutus on yhden reitin poistaminen.