Kaksi toimipaikkaa, yksi aliverkko: rakenna kummallekin alias-näkymä
Kun kaksi toimipaikkaa käyttää samaa lähiverkkoa, anna kummallekin alias-etuliite ja käännä molempiin suuntiin. Tarkista törmäykset, peittoverkon käytäntö, DNS-nimet ja kirjaus.
Kaksi asiakastoimipaikkaa käyttävät molemmat 192.168.50.0/24-verkkoa, ja etäinsinöörin on päästävä samassa osoitteessa olevaan tulostimeen kummassakin. Mikään reitityskikka ei ratkaise tätä monitulkintaisuutta yksinään. Kumpikin toimipaikka tarvitsee oman osoitenäkymän, ja yhdyskäytävän on valittava toimipaikka tästä näkymästä ennen kuin se välittää mitään.
Suunnitelmassa on neljä osaa: alias-etuliitteet, molemmat käännössuunnat, peittoverkon käytäntö ja nimet. Jokaisen on sovittava muiden kanssa.
Valitse yksi alias-etuliite toimipaikkaa kohden
Anna kullekin toimipaikalle kokonainen alias-etuliite, joka ei kuulu kenellekään muulle ympäristössä. Kahden toimipaikan suunnitelmassa toimipaikan A 192.168.50.0/24 voi yhdistää osoitteeseen 172.21.10.0/24 ja toimipaikan B samanlainen lähiverkko osoitteeseen 172.21.20.0/24. Tarkista ehdokkaat jokaista osallistuvaa verkkoa vastaan, mukaan lukien pilven VPC:t ja muut VPN-altaat. Yksityisen osoiteavaruuden jakaa jokainen organisaatio, joten se, että alue on RFC 1918, ei kerro mitään siitä, onko se täällä vapaa.
Julkaise alias, älä alkuperäistä aliverkkoa, etäkäyttäjille. Alkuperäinen alue jää paikalliseksi tosiasiaksi.
Käännä molempiin suuntiin
Käännä molempiin suuntiin. Kohdekuvaus kirjoittaa alias-osoitteen uudelleen alkuperäiseksi osoitteeksi omistavassa toimipaikassa. Lähdekuvaus kirjoittaa etäkutsujan uudelleen aliakseksi, jonka muut toimipaikat voivat erottaa.
Staattinen yksi-yhteen-kuvaus on deterministinen, eikä se tee toteutuksesta tilatonta. Käänteinen käännös voi riippua yhteyden tilasta, ja vikasietoon siirtyminen tai epäsymmetriset polut voivat rikkoa suunnitelman, joka jättää sen huomiotta. Alustan dokumentaatio päättää, mikä näistä pätee.
Tarkka vaihe, jossa käytäntö, valitsimet ja reitit otetaan käyttöön, eroaa käytäntöpohjaisen IPsecin, reittipohjaisten tunnelien ja muiden tuotteiden välillä. Suunnittele sille, jota ajat.
Kuljeta suunnitelma peittoverkon läpi
Keskittimessä osoita kukin alias-etuliite sen omistavalle toimipaikkapolulle ja salli vain tehtävän tarvitsema läpikulku. Verkossa jokainen asiaankuuluva vastapuoli tarvitsee saman etuliitteen ja käytäntötiedon. Tunnelien lisääminen ei korjaa monitulkintaista osoitteistusta itsessään.
Koko aliverkon julkaisu on laajempaa kuin yhden palvelun julkaisu. Jos tarvitaan vain muutama kone tai portti, pidä käyttösäännöt kuvauista kapeampina.
Otsikkokäännös ei kirjoita sovelluksen hyötykuormia uudelleen. Uudelleenohjaukset, kokoonpanotiedostoihin upotetut osoitteet ja lähdeperusteiset käyttöoikeudet voivat kaikki yhä kantaa alkuperäistä osoitetta. Testaa sovelluspolku, älä vain ping. Toimiva ICMP-vastaus todistaa, että kuvaus on olemassa, eikä kerro mitään siitä, hyväksyykö sovellus aliaksen.
Korjaa nimet, jotka kukin kutsuja näkee
Anna ylläpitonimille vastaukset, jotka vastaavat kutsujan näkymää. Jos etäinsinööri selvittää isäntänimen, sen pitäisi palauttaa kyseisen toimipaikan alias-osoite, ei jaettua alkuperäistä aluetta.
Tarkista DNS-näkymät toimipaikoittain ennen ensimmäistä ylläpitoikkunaa. Nimi, joka selvitys alkuperäiseksi aliverkoksi, lähettää kutsujan takaisin siihen monitulkintaisuuteen, joka suunnitelman piti poistaa.
Kirjaa ja varmenna toimipaikoittain
Vastaanota kukin toimipaikka erikseen todelliselta kutsujalta ja vahvista, mikä kone vastasi. Kirjaa alkuperäinen osoite, alias, omistava yhdyskäytävä ja sallittu palvelu yhteen.
Juuri tämä luettelo säilyttää eron, kun kolmas toimipaikka saapuu samalla oletuslähiverkolla. Käytäntöpohjaisen IPsec NAT -opas dokumentoi yhden konkreetin käännösmallin; se ei ole sopimus kaikille alustoille.