Dy sajte, një nënrrjet: ndërtoni një pamje alias për secilin

Dy sajte klientësh përdorin të dy 192.168.50.0/24, dhe një inxhinier në distancë duhet të arrijë një printer në të njëjtën adresë në secilin. Asnjë truk rrugëtimi nuk e zgjidh vetë atë paqartësi. Secili sajt ka nevojë për një pamje të veçantë adresash, dhe porta duhet ta zgjedhë sajtin nga ajo pamje përpara se të përcjellë çdo gjë.

Plani ka katër pjesë: prefikset e aliasit, të dy drejtimet e përkthimit, politika e mbivendosjes dhe emrat. Secila duhet të pajtohet me të tjerat.

Zgjidhni një prefiks alias për çdo sajt

Jepini secilit sajt një prefiks alias të plotë që nuk i përket askujt tjetër në mjedis. Një plan për dy sajte mund të hartojë 192.168.50.0/24 të sajtit A në 172.21.10.0/24 dhe LAN-in identik të sajtit B në 172.21.20.0/24. Kontrolloni kandidatët kundrejt çdo rrjeti pjesëmarrës, përfshirë VPC në re dhe grupe të tjera VPN. Hapësira e adresave private ndahet nga çdo organizatë, prandaj fakti që një interval është RFC 1918 nuk thotë asgjë për atë nëse është i lirë këtu.

Publikoni aliasin, jo nënrrjetin origjinal, për përdoruesit në distancë. Intervali origjinal mbetet një fakt lokal.

Përktheni në të dy drejtimet

Përktheni në të dy drejtimet. Hartëzimi i destinacionit rishkruan një adresë alias në adresën origjinale në sajtin që e zotëron. Hartëzimi i burimit rishkruan thirrësin në distancë në një alias që sajtet e tjera mund ta dallojnë.

Një hartëzim statik një-për-një është përcaktues, dhe kjo nuk e bën zbatimin pa gjendje. Përkthimi i kundërt mund të varet nga gjendja e lidhjes, dhe kalimi në rezervë ose rrugët asimetrike mund të prishin një plan që e injoron atë. Dokumentacioni i platformës vendos cila prej tyre zbatohet.

Faza e saktë ku zbatohen politika, selektorët dhe rrugët ndryshon midis IPsec të bazuar në politika, tuneleve të bazuara në rrugë dhe produkteve të tjera. Dizajnoni për atë që ekzekutoni.

Çojeni planin përmes mbivendosjes

Në një hub, caktoni çdo prefiks alias te rruga e sajtit që e zotëron dhe lejoni vetëm transitin që i duhet detyrës. Në një rrjetë, çdo palë përkatëse ka nevojë për të njëjtin prefiks dhe njohuri politike. Shtimi i tuneleve nuk e rregullon vetë adresimin e paqartë.

Publikimi i të gjithë nënrrjetit është më i gjerë se publikimi i një shërbimi të vetëm. Nëse nevojiten vetëm disa makina ose porta, mbani rregullat e aksesit më të ngushta se hartëzimi.

Përkthimi i kokës nuk i rishkruan ngarkesat e aplikacionit. Ridrejtimet, adresat e integruara në skedarët e konfigurimit dhe lejet e bazuara në burim mund të vazhdojnë të mbajnë adresën origjinale. Testoni rrugën e aplikacionit, jo vetëm ping-un. Një përgjigje ICMP që funksionon dëshmon se hartëzimi ekziston dhe nuk thotë asgjë nëse aplikacioni e pranon aliasin.

Rregulloni emrat që sheh çdo thirrës

Jepini emrave të mirëmbajtjes përgjigje që përputhen me pamjen e thirrësit. Nëse inxhinieri në distancë zgjidh një emër pritësi, ai duhet të kthejë adresën e aliasit për atë sajt, jo intervalin origjinal të përbashkët.

Kontrolloni pamjet DNS për çdo sajt përpara dritares së parë të mirëmbajtjes. Një emër që zgjidhet në nënrrjetin origjinal e kthen thirrësin në paqartësinë që plani duhej të hiqte.

Regjistroni dhe verifikoni për çdo sajt

Pranoni çdo sajt veçmas nga një thirrës i vërtetë dhe konfirmoni cila makinë u përgjigj. Regjistroni bashkë adresën origjinale, aliasin, portën që e zotëron dhe shërbimin e lejuar.

Ky inventar është ai që ruan dallimin kur arrin një sajt i tretë me të njëjtën LAN të parazgjedhur. Udhëzuesi i IPsec NAT të bazuar në politika dokumenton një model konkret përkthimi; nuk është kontratë për çdo platformë.