Site-to-Site VPN AWS:stä Azureen: kirjoita paluureitti ensin
Yhdistetty pilvienvälinen tunneli ei todista mitään ennen kuin jokainen työkuorman aliverkko reitittää etäprefiksiin. Käy suunnitelma järjestyksessä läpi ja testaa sitten palvelu.
Tunneli nousee. Yleensä niin käy, koska IKE tarvitsee vain täsmäävät ehdotukset ja tavoitettavan vastapuolen osoitteen. Sen jälkeen pettää paluureitti: AWS:n työkuorma lähettää paketit tunneliin, mutta Azurella ei tiedetä, miten 10.10.0.0/16:een vastataan, tai Azure-reitti on taulussa, jota työkuorman aliverkko ei käytä. Kirjoita reittisuunnitelma ennen kuin kosket kumpaankaan konsoliin, niin tunnelista tulee työn vähiten kiinnostava osa.
Vaihe 1: jäädytä osoitesuunnitelma
Työskentele konkreettisilla arvoilla. AWS:n työkuorma on 10.10.1.20:ssä 10.10.0.0/16:n sisällä ja tarvitsee TCP 443:n Azure-palveluun 10.20.1.30:ssä 10.20.0.0/16:n sisällä. Alueet eivät saa mennä päällekkäin, ja hyväksymistesti on palvelupari, ei tunneli.
Kirjoita nuo neljä tosiasiaa ennen kaikkea muuta, koska jokainen myöhempi vaihe tarkistetaan niitä vasten.
Vaihe 2: nimeä yhdyskäytävä, joka omistaa kummankin pään
AWS Site-to-Site VPN voi päättyä virtuaaliseen yksityiseen yhdyskäytävään tai transit-yhdyskäytävään, ja ne ovat eri reititysomistajia. Azure tarjoaa hallitun VPN Gateway -palvelunsa ja erikseen asiakkaiden itse ajamat VM-pohjaiset laitteet. Kirjaa, kumpi pari sinulla on, koska seuraava hyppy eroaa jokaisessa yhdistelmässä.
Hallitulle yhdyskäytävälle älä kopioi reittiä, joka osoittaa arvattuun yksityisen laitteen osoitteeseen. Laitteelle älä oleta, että pilven reittijakelu määrittää vieraskäyttöjärjestelmän, koska se ei tee niin.
Tämän väärin tekeminen tuottaa suunnitelman, joka näyttää valmiilta ja lähettää paketit osoitteeseen, joka ei koskaan vastaa.
Vaihe 3: kirjoita reitti, jota kukin työkuorma todella käyttää
Jokainen alla oleva raja on erillinen haku, eikä yhden niistä reitti ole paketin reitti. Täytä taulukko omilla arvoillasi ennen kuin tunneli otetaan käyttöön.
| Boundary | Must reach | Owner to inspect |
|---|---|---|
| AWS workload subnet | 10.20.0.0/16 | the subnet's VPC route table |
| AWS transit gateway, if used | 10.20.0.0/16 via the VPN attachment | the table associated with that attachment |
| Azure workload subnet | 10.10.0.0/16 | effective routes on the NIC, whatever their source |
| VPN scope | both prefixes, agreed | static connection ranges or BGP advertisements |
AWS:ssä työkuorman aliverkon reititystaulukko on sinun päivitettäväsi vielä sen jälkeenkin, kun BGP tai tunneli on kunnossa; reitityksen yleiskatsaus pitää sitä osana yhteyttä. Azuressa käyttäjän määrittämä reititystaulukko liitetään aliverkkoon eikä virtuaaliverkkoon, joten tarkista tehollinen reitti työkuorman NIC:ltä, älä VNet-sivulta.
Hallittu Azure-yhdyskäytävä voi oppia etäprefiksin yhdyskäytävän jakelun kautta, ja UDR voi kumota tämän päätöksen. Lisää UDR, kun sinulla on syy, ei refleksinä. Jos lisäät, osoita se seuraavaan hyppyyn, jonka yhdyskäytävä julkaisee VPN-polulle, älä keksi laitteen osoitetta. Lue sitten teholliset reitit NIC:ltä uudelleen, koska päätös tehdään todella siellä.
Vaihe 4: sovita laajuus
BGP:ssä vertaa, mitä kumpikin puoli ilmoittaa, siihen, mitä toinen puoli todella oppi, prefiksi prefiksiltä. Staattisessa reitityksessä vertaa määritettyjä etäalueita vaiheessa 3 kirjoittamiisi työkuorman reitteihin.
IKE-suhde, joka on yksimielinen salauksesta, ei todista, että kumpikaan puoli oppi 10.10.0.0/16:n tai 10.20.0.0/16:n. Kaksi tunnelia voi olla pystyssä, kun toinen puoli ilmoittaa yhden /24:n suunnittelemasi /16:n sijaan. Tarkista prefiksi reititystaulukosta, ei tunnelin tilasta. Epäsuhta näkyy myöhemmin yhtenä toimivana ja yhtenä koskaan vastaamattomana aliverkkona.
Vaihe 5: testaa palvelu oikeasta lähteestä
Salli aiottu virta AWS:n suojausryhmissä ja verkon ACL:issä, Azure NSG:issä ja missä tahansa polun laitesuodattimessa. Avaa sitten yksi yhteys 10.10.1.20:stä hyväksyttyyn palvelun osoitteeseen ja porttiin ja varmista, että vastaus palaa samaan lähteeseen.
Sekä pilven suojausryhmät että NSG:t ovat tilallisia, joten hylätty paluupaketti on reititysoire, ei sääntö, jonka unohdit kirjoittaa käänteisesti.
Ping mistä tahansa yhdyskäytävästä ei ratkaise mitään. ICMP yhdyskäytävän osoitteeseen harjoittaa ohjaustason polkua, ei välitettyä TCP-palvelua, jota työkuorma tarvitsee.
Palautus ja kirjaukset
Kirjaa reittien omistajat tunnelin tunnisteiden viereen ja säilytä muutosta edeltävät reititystaulukot. Jos muutos on purettava, poista työkuorman reitit ennen tunnelin purkamista, jotta mikään aliverkko ei jää osoittamaan seuraavaan hyppyyn, jota ei enää ole.
Myöhemmällä aliverkon siirrolla tai spoke-liitoksella on silloin yksi määritetty päivityspaikka, eikä toimiva tunneli, joka kantaa syyn reitistä, jota se ei koskaan omistanut.