Može li jedan WAN interfejs nositi vezu između lokacija i udaljene korisnike?

Jedna javna adresa može istovremeno opsluživati tunel podružnice i bazen korisnika u pokretu. Ali ne može opsluživati jedno zajedničko pravilo prijema. Peer podružnice i korisnik u pokretu razlikuju se po tome kako dokazuju ko su, kako se taj dokaz provjerava, koje adrese dobijaju i koji prefiksi smiju odgovarati na njih. Kad vanjsku adresu počnete tretirati kao transportni detalj, a ne kao identitet, dizajn postaje mnogo jednostavniji.

Brza provjera zdravog razuma: pokušajte napisati oba zapisa prijema prije nego što dotaknete ruter. Ako jedan uvjet uparivanja mora pokriti oboje, politika je već dvosmislena, a prvi simptom će izgledati kao kvar rutiranja ili firewall-a, iako je zapravo kvar identiteta.

Dva zapisa prije bilo kakve konfiguracije

Zapis podružnice je kratak i stabilan. Navodi adresu peer-a ili ime certifikata, unaprijed dijeljeni ključ ili trustpoint certifikata, zaštićene podmreže s obje strane, interfejs tunela i statičku rutu koja promet prema podružnici šalje u taj tunel. Svako polje tiče se jednog poznatog peer-a i fiksnog skupa prefiksa.

Zapis za korisnike u pokretu širi je i osobniji. Navodi protokol i port klijenta, način na koji se korisnik ili uređaj autentikuje, bazen adresa koji se dodjeljuje pri spajanju, resurse do kojih taj bazen smije doći, prefikse podijeljenog tunela, DNS servere koji se guraju klijentu i svaki drugi faktor. Svako polje odgovara na pitanje o nepoznatom broju korisnika, a ne o jednom gateway-u.

Ta razlika u granularnosti cijeli je razlog zašto se dvije uloge razilaze. Profil podružnice može sigurno vjerovati jednom ključu jer ključ pripada jednom uređaju na jednoj lokaciji. Profil za korisnike u pokretu koji vjeruje jednom grupnom ključu za sve ruši odgovornost po korisniku, što se obično otkrije kasnije, tijekom analize incidenta, a ne tijekom uvođenja.

Gdje se razilaze uparivanje peer-a i autentikacija

Na IOS XE IKEv2 profil nosi parametre o kojima se ne može pregovarati i uvjete koji se koriste za odabir peer-a. To znači da strana podružnice i strana korisnika u pokretu trebaju svaka svoj profil, čak i kad završavaju na istom interfejsu i čak kad dijele jedan kripto PKI. Cisco dokumentuje uloge profila, autentikacije i uparivanja u svom vodiču za konfiguraciju IKEv2 za IOS XE 17.

Profil podružnice obično uparuje uski identitet: udaljenu adresu, FQDN ili subjekt certifikata. Nešto poput match identity remote address 198.51.100.10 255.255.255.255 prikiva jedan peer, a authentication remote pre-share s ključem koji se čuva po lokaciji dovoljno je. Držite uparivanje što preciznijim koliko inventar peer-ova dopušta, jer preklapajući wildcard viši u redoslijedu odabira može povući promet podružnice u pogrešan profil.

Profil za korisnike u pokretu ne može prikivati adresu, pa se uparuje s grupom, key-id-om ili poljem certifikata, a onda pravu provjeru korisnika predaje AAA ili politici autorizacije vezanoj uz profil. Ta podjela je važna: autentikacija peer-a odgovara smije li klijent graditi tunel, a autorizacija po korisniku odgovara koji bazen i koje resurse dobija. Korištenje ključa podružnice kao univerzalne prijave odbacuje drugi odgovor.

Prosljeđivanje i prevođenje trebaju istu podjelu

Prijem i dostupnost su odvojeni problemi. Uspješna razmjena IKE i IPsec dokazuje da su strane suglasne o ključevima; ona ne stvara rutu do bazena koji je klijent dobio. Zato bazenima udaljenog pristupa treba povratna putanja, bilo statička ruta prema interfejsu tunela, bilo protokol rutiranja koji ubacuje sažetak bazena. Prefiksi podružnice obično dolaze kroz isti proces rutiranja koji opslužuje ostatak lokacije.

Prevođenje je mjesto gdje se dvije uloge najčešće sudaraju. Promet između lokacija koji mora zadržati svoje privatne adrese treba izuzeće od NAT-a ograničeno na ta dva prefiksa, u oba smjera. Klijentima u pokretu obično treba izuzeće i za promet u tunelu, ali njihov promet prema internetu ili zaobilazi tunel kroz podijeljeni tunel, ili izlazi na koncentratoru nakon NAT-a. Izuzeće svega što dolazi iz tunela klasična je pogreška, jer ono ukida prevođenje i prometu kojem ono doista treba.

Držite pravila izuzeća uskim kao i pravila prijema. Ako se sažetak bazena i prefiks podružnice preklope, povratna putanja postaje dvosmislena mnogo prije nego što se ijedan paket odbaci, a simptom se pojavljuje kao lokacija koja s vremena na vrijeme gubi podmrežu, a ne kao čist kvar tunela.

Prihvatni slučajevi koji razotkrivaju ukrštenu politiku

Sastavite četiri slučaja i izvedite ih po redu. Host u podružnici dolazi do resursa samo za podružnicu. Klijent u pokretu dolazi do istog resursa preko adrese iz svog bazena. Klijent u pokretu pokušava doći do prefiksa podružnice koji ne smije doticati. Peer podružnice pokušava dobiti adresu iz bazena udaljenog pristupa. Posljednja dva slučaja hvataju zajednički profil, jer tiho padaju u uobičajenom nadzoru.

Zatim potvrdite podatkovnu ravninu, a ne konfiguraciju. show crypto ikev2 sa i show crypto ipsec sa kažu koji su profil i koji selektori nosili svaki tok, a show ip nat translations i brojači tunela pokazuju jesu li se povratna putanja i izuzeće doista poklopili. Tracer ili snimanje paketa na interfejsu tunela zatvara krug.

Zapišite uočeni identitet, adresu iz bazena i odabranu politiku uz svaki rezultat. Prolaz je završen kad svaki slučaj odgovara točno jednom zapisu i nijednom slučaju ne treba privremeno izuzeće da bi prošao.