Azure VPN:n NAT ei korjaa päällekkäisiä VNet-osoitteita

Molemmat VNetit käyttävät aluetta 10.40.1.0/24, tunnelit nousevat pystyyn, eikä mikään toimi. Toisen VPN-yhdyskäytävän lisääminen ei muuta sitä, eikä myöskään pienempi reittimetriikka, koska ongelma ei ole polun valinnassa. Kaksi työkuormaa, jotka vastaavat samaan yksityiseen osoitteeseen, jättävät jokaisen paketin epäselvään kohteeseen ja vahvistamattomaan paluupolkuun. Ennen minkään käännöksen suunnittelua selvitä, minkä yhteystyypin todella loit, sillä tuo yksi valinta ratkaisee, onko Azuren NAT-ominaisuus ylipäätään käytettävissä.

Mitä oire oikeastaan kertoo sinulle

Kun VNet A:n isäntä lähettää osoitteeseen 10.40.1.10, reititystaulukko voi vain osoittaa sen jonnekin. Jos myös VNet B sisältää osoitteen 10.40.1.10, tuo osoite ei ole kohde, jonka polku voi erottaa; se on yksi osoite kahdella omistajalla.

Toinen yhdyskäytävä, joka yleensä otetaan käyttöön, ei auta. Se antaa toisen tunnelin, ei toista osoitetta, ja päällekkäinen alue kulkee tunnelissa muuttumattomana. Se myös kaksinkertaistaa kokoonpanon, joka sinun on pidettävä yhtenäisenä. Se, mitä se ei voi tehdä, on saada yksi osoite tarkoittamaan kahta isäntää.

VPN-vertaisten julkisten osoitteiden muuttaminen ei myöskään tee mitään. Ne osoitteet määrittävät tunnelin päätepisteet, kun taas törmäys on sisällä kuljetettavassa yksityisessä alueessa.

Yhteyden tyyppi ratkaisee, onko NAT käytettävissä

Azure VPN Gatewayllä on todella NAT-ominaisuus, ja se on dokumentoitu reittipohjaisille IPsec-toimipaikkojen välisille yhteyksille tietyillä yhdyskäytävän SKUilla. Sama dokumentaatio sulkee pois VNet-to-VNet- ja point-to-site-yhteydet, joten ominaisuus ei ole valintaruutu, joka ilmestyy jokaiseen yhdyskäytävän suhteeseen.

Natiivi VNet-to-VNet edellyttää myös, että VNetin ja paikallisen verkon alueet eivät ole päällekkäisiä alusta alkaen, mikä on linjassa poissulkemisen kanssa. VNet-vertaisuus ei ole päällekkäisyyden ratkaisu samasta syystä.

On olemassa tuettu vaihtoehto, jonka ihmiset sekoittavat natiiviin tyyppiin: mallinna toinen VNet paikalliseksi verkoksi ja yhdistä se toimipaikkojen väliseksi yhteydeksi. Se on eri resurssi ja eri suunnittelu, joten kohtele uudelleennimettyä yhteyttä validoitavana muutoksena, älä pelkkänä nimenmuutoksena.

Numeroi uudelleen tai käännä jollakin, joka omistaa aliaan

Jos molemmat VNetit ovat sinun, vertaa suunniteltua uudelleennumerointia käännöksen jatkuvaan kustannukseen. Uudelleennumerointi koskettaa sovellusten kokoonpanoa, DNS-tietueita, suojaussääntöjä ja jokaista olemassa olevaa yhteyttä, mutta jättää verkon, joka luetaan sen jälkeen normaalisti. Tee se yksi aliverkko kerrallaan, DNS-muutos viimeisenä. Puoliksi uudelleennumeroitu alue on huonompi kuin kumpikaan vaihtoehto, koska silloin molemmat etuliitteet näyttävät valtuutetuilta seuraavalle taulukon lukijalle.

Kun uudelleennumerointi ei ole käytännöllistä, käytä käännettyä suunnittelua, jolla on aliakselle todellinen omistaja. VNet A:n kutsujat voivat tavoittaa VNet B:n osoitteen 10.40.1.10 osoitteena 10.140.1.10, mutta tuo alias tarvitsee laitteen, joka kääntää, reitin sitä kohti ja vastaavan käyttäytymisen vastaukselle. Pelkkä DNSään lisätty osoite ei ole käännös.

Kirjaa molemmat alueet molempiin suuntiin: mitä kutsuja valitsee, mitä kohde näkee lähteenä ja kumpi puoli voi aloittaa. Azuren omat NAT-säännöt sisältävät käänteisen käännöksen SNAT-mappauksilleen, joten et kirjoita vastaavaa DNAT-sääntöä käsin, mutta tämä mukavuus päättyy niihin yhteystyyppeihin, joita ominaisuus tukee.

Mikä ei toimi

Käyttäjän määrittämä reitti tai reittimetriikka ei voi luoda puuttuvaa osoite-eroa. Molemmat toimivat kohteessa, joka on edelleen epäselvä, ja paketti saapuu sille seuraavalle hypylle, jota taulukko suosii.

Päällekkäisen alueen lisääminen reititystaulukkoon tarkempana etuliitteenä siirtää epäselvyyttä vain yhden askeleen. Se myös rikkoo helposti toista suuntaa, jossa vastauksella on nyt kaksi uskottavaa lähdettä.

Hyväksy suunnittelu liikenteellä molempiin suuntiin

Todista suunnittelu tuoreella sallitulla toiminnolla kummaltakin puolelta, älä tunnelin tilalla. Yhdistetty IPsec-tunneli kertoo, että vertaiset ovat yksimielisiä salauksesta; se ei kerro mitään siitä, tulivatko kohteet erotettaviksi.

Aja sitten kielletyt polut: osoite, jonka pitäisi pysyä tavoittamattomana, ja palvelu, jonka käytännön pitäisi estää. Jos molemmat yhä onnistuvat, käännös on laajempi kuin suunnittelu tarkoitti.

Päätä faktoihin, jotka selittävät asetelman myöhemmin: alkuperäinen alue, esitetty alue, käännöksen tekevä laite ja suunta, jossa kumpi tahansa puoli voi aloittaa. Jos jokin näistä puuttuu, seuraava insinööri perii verkon, jossa kaksi isäntää jakaa nimen eikä kukaan muista, miksi yksi heistä vastaa.