Relay DHCP i ASA-s përmes një VPN site-to-site: udhëzues hap pas hapi

Relay-i punon në tri faza dhe vetëm faza e mesme kalon VPN-në. Një klient transmeton në segmentin e degës, ASA e kthen atë transmetim në një kërkesë unicast drejt serverit DHCP, dhe serveri përgjigjet në adresën e relay-it, jo te klienti. Kaloni fazat në këtë rend, dhe shumica e rasteve «relay-i është prishur» përfundojnë në një politikë që mungon ose në një rresht setroute të lexuar gabimisht.

Faza e parë: aktivizoni relay-in në ndërfaqen përballë klientëve

Në ASA-në e degës, relay-i është veti e ndërfaqes që shikon drejt klientëve. Serveri mund të deklarohet globalisht me ndërfaqen e tij të arritshme, ose nën atë ndërfaqe përballë klientëve, që tabela e rrugëzimit të zgjedhë daljen. Këto dy forma nuk janë të këmbyeshme, dhe kopjimi i asaj të gabuar është vendi i parë ku një udhëzues devijon.

Kontrolloni konfigurimin në punë përpara se të ndryshoni çdo gjë: cila ndërfaqe e ka relay-in të aktivizuar, cila formë serveri është e pranishme dhe a është setroute i lidhur me ndërfaqen e klientit. Nëse ASA drejton edhe një server DHCP për një segment tjetër, ndaloni dhe lexoni listën e kufizimeve; serveri dhe relay-i nuk mund të aktivizohen njëkohësisht në të njëjtën pajisje.

Relay-i vendos adresën e vet përballë klientëve në fushën e adresës së gateway-it. Pikërisht kësaj adrese do t'i përgjigjet serveri, prandaj duhet të jetë e arritshme nga vendi i largët përmes tunelit, jo vetëm lokalisht.

Faza e dytë: çoni trafikun që gjeneron ASA përmes tunelit

Ky është hapi që njerëzit e kapërcejnë. Një VPN site-to-site e bazuar në politika zakonisht ndërtohet për trafikun midis subnet-eve, dhe kërkesën e relay-it e gjeneron vetë ASA. Nëse lista e aksesit e tunelit dhe harta kriptografike përputhen vetëm me rrjedhat nga hosti i degës drejt subnet-it të serverit, paketa e relay-it mund të mos hyjë kurrë në tunel. Kontrolloni listën e aksesit në të dy drejtimet, jo vetëm rreshtin nga dega drejt serverit.

Konfirmoni që trafiku me interes mbulon burimin e relay-it të ASA-s dhe adresën e serverit, dhe se drejtimi i kthimit lejohet gjithashtu. Në një projekt të bazuar në VTI vendimi i rrugëzimit është më i thjeshtë, por mbështetja e relay-it mbi VTI erdhi në një version të caktuar; udhëzuesi DHCP i ASA-s përmend 9.14(1), prandaj kontrolloni imazhin përpara se të kopjoni një shembull VTI në një pajisje më të vjetër.

Një ping nga ASA te serveri provon pak më vete. Mund të ketë sukses në një rrugë tjetër, me një adresë burimi tjetër, ose nën një politikë me të cilën paketat e relay-it nuk përputhen.

Faza e tretë: lexoni përgjigjjen dhe opsionin setroute

RFC 2131 thotë se serveri e dërgon përgjigjjen te adresa në giaddr kur ajo fushë nuk është zero. Pra rruga e kthimit duhet të rrugëzohet drejt adresës së relay-it, dhe politika e tunelit duhet të lejojë drejtimin nga serveri te relay-i. Nëse kërkesa kaloi por oferta nuk arrin kurrë, këtu duhet parë.

Pastaj ndani dy gjëra që tingëllojnë njësoj. Fjala kyçe setroute ndryshon ose shton opsionin e router-it të parazgjedhur që ASA i jep klientit. Ajo nuk instalon një rrugë në ASA dhe nuk krijon politikë VPN. Një klient që merr adresë por nuk arrin gjë ka shpesh problem setroute ose shtrirjeje, jo problem tuneli. Provojeni me një klient pa gateway statik dhe vëzhgoni cili router i parazgjedhur shfaqet në ofertë.

Lexoni ofertën nga fillimi në fund: adresa e ofruar, maska, router-i i parazgjedhur, DNS dhe koha e qirasë. Pastaj lini qiranë të përtërihet. Një relay që punon një herë dhe dështon në përtëritje zakonisht ka problem shtrirjeje, qiraje ose rruge kthimi që shkëmbimi i parë e fshehu.

Çfarë kontrolloj përpara se ta quaj të rregulluar

Filloni nga klienti dhe kapni transmetimin, pastaj konfirmoni se ASA e transmetoi me adresën e vet si giaddr. Në anën e largët konfirmoni se serveri e pa atë kërkesë dhe zgjodhi një shtrirje që përputhet me degën. Kthyer në degë, konfirmoni se klienti e pranoi ofertën dhe arrin gateway-in e vet.

Nëse ndonjë fazë është e heshtur, kontrolloni politikën ose rrugën përkatëse në vend që të shtoni një deklaratë tjetër relay. Konfigurimi i relay-it zakonisht është tashmë i saktë kur dikush e eskalon çështjen; ajo që ka ndryshuar është politika e tunelit ose rruga e kthimit.

Shkruani tri fazat në regjistrin e ndryshimeve: ndërfaqja përballë klientëve, politika VPN që mbulon trafikun e relay-it dhe rruga e kthimit të serverit te giaddr. Ky regjistër është ai që e bën ndërtimin e degës së radhës punë të përsëritshme në vend të një sesioni korrigjimi. Ai gjithashtu i thotë inxhinierit të radhës cilin dalje komande të mbledhë së pari.