Razširitev mesta VPN: sledite povratni poti za prehodom
Razširitev mestnega VPN v drug center podatkov zahteva pot naprej in povratno pot, ne le še ene predpone na bližnjem prehodu.
Promet iz podružnice se konča na prehodu, katerega LAN ne vsebuje aplikacije, do katere bi morali priti. Strežnik je v drugem centru podatkov, za notranjo povezavo, ki je VPN nikoli ni konfiguriral. Dodajanje še ene predpone bližnjemu prehodu za ta primer ne naredi ničesar, ker je oddaljeni prehod končna točka šifriranja in ne zadnji usmerjevalnik. Pot potrebuje pot naprej, dovoljenje na oddaljeni varnostni meji in odločitev o vrnitvi v samem omrežju cilja.
Oddaljeni prehod je končna točka šifriranja
IPsec med prehodi ščiti promet med dvema varnostnima napravama, notranji naslovi pa ta odsek prepotujejo šifrirani. Za oddaljenim prehodom prevzame običajno usmerjanje, vključno s katero koli politiko, ki obstaja med centri podatkov. Zaščiteni odsek torej pokriva del potovanja in ne preostanka. Predpostavljati nasprotno je način, kako se zasnova konča z zdravim tunelom in nedosegljivo aplikacijo.
Narišite pot v treh delih: podružnica do bližnjega prehoda, bližnji do oddaljenega, oddaljeni prehod do aplikacije. Vsak del ima svojega lastnika in svoj način odpovedi.
Preberite obe smeri politike tunela
Politika tunela se običajno piše z vidika lokalne strani in prav iz te navade izhajajo delne konfiguracije. Obe strani morata navesti vir podružnice in cilj tako, kot se bosta pojavila znotraj tunela, vključno s katero koli pretvorbo, ki jo zasnova predvideva. Posodobitev samo bližnjega konca povzroči neskladje druge faze, ki je videti kot odpoved usmerjanja. Primerjajte oba nabora politik, preden se dotaknete katere koli poti.
Vir in cilj zapišite kot naslove in ne kot imena mest. Dvoumnost se tukaj pozneje vrne kot zmedena asimetrija.
Dodajte pot naprej in potrdite dovoljenje
Oddaljeni prehod potrebuje pot do podomrežja aplikacije, vsak usmerjevalnik med njima pa mora dovoliti vir podružnice. Preverite, kaj oddaljeni prehod v resnici ima, namesto kaj trdi diagram.
ip route get 10.30.5.10 from 10.10.1.50
traceroute -n -s 10.10.1.50 10.30.5.10Prvi ukaz poroča o izhodnem vmesniku in naslednjem skoku, ki bi ju oddaljeni prehod izbral za ta vir, kar je vprašanje, na katero običajna usmerjevalna tabela ne more odgovoriti. Sled kaže, kje se paketi ustavijo, prekinitev za oddaljenim prehodom pa kaže na notranji tranzit in ne na tunel. Ko pot obstaja in promet še vedno izginja, zajemite na oddaljenem prehodu in preberite prihajajoči naslov vira, ker nepričakovan naslov pomeni, da se pretvorba dogaja nekje nenačrtovano. Vsi naslovi tukaj so nadomestni znaki, zato jih zamenjajte z resničnimi podomrežji podružnice, tranzita in aplikacije.
Preizkusite iz podružnice, nato znova preizkusite staro pot
Sprejem potrebuje resničen vir in ne sonde z oddaljenega prehoda. Zaženite preverjanje z gostitelja v podružnici in ohranite prej delujoče cilje v istem preizkusu.
curl -sS -m 5 http://10.30.5.10:8080/health
ping -c 3 10.20.1.1Odziv aplikacije dokaže pot naprej in povratno pot skupaj, ping na stari cilj pa dokaže, da sprememba ni pokvarila tega, kar je že delovalo. Zajemite naslov vira, ki ga beleži aplikacija, ker se morajo njena pravila dostopa in katera koli povratna pot ujemati s to vrednostjo. Kjer podružnica pretvarja pred tunelom, se naslov iz politike in naslov, ki ga vidi aplikacija, po zasnovi razlikujeta, zato zapišite oba. Ponovite preizkus po obnovitvi ključa ali spremembi usmerjanja, ker se te poti običajno preverijo enkrat in nato pozabijo.
Vsakemu od treh odsekov in povratni poti znotraj ciljnega omrežja dodelite lastnika. Pot s štirimi lastniki odpove v vrzelih med njimi.