ASA DHCP relay pār site-to-site VPN: soli pa solim
Izejiet trīs ASA DHCP relay posmus pār site-to-site VPN: klienta saskarne, relay trafika tuneļa politika un atbilde uz giaddr.
Relay darbojas trīs posmos, un tikai vidējais šķērso VPN. Klients raida apraidi filiāles segmentā, ASA pārvērš šo apraidi unicast pieprasījumā DHCP serverim, un serveris atbild uz relay adresi, nevis uz klientu. Izejiet posmus šajā secībā, un vairums gadījumu «relay ir salūzis» nonāk pie trūkstošas politikas vai nepareizi nolasītas setroute rindas.
Pirmais posms: ieslēdziet relay klienta puses saskarnē
Filiāles ASA relay ir tās saskarnes īpašība, kas vērsta pret klientiem. Serveri var deklarēt globāli ar tā sasniedzamo saskarni vai zem šīs klienta puses saskarnes, lai maršrutēšanas tabula izvēlētos izeju. Šīs divas formas nav savstarpēji aizstājamas, un nepareizās kopēšana ir pirmā vieta, kur pamācība aiziet greizi.
Pirms kaut ko mainīt, pārbaudiet darbojošos konfigurāciju: kurai saskarnei ir ieslēgts relay, kāda servera forma ir, un vai setroute ir piesaistīts klienta saskarnei. Ja ASA vienlaikus darbojas arī kā DHCP serveris citam segmentam, apstājieties un izlasiet ierobežojumu sarakstu; serveri un relay nevar ieslēgt vienlaikus vienā ierīcē.
Relay ievieto savu klienta puses adresi vārtejas adreses laukā. Tieši uz šo adresi serveris atbildēs, tāpēc tai jābūt sasniedzamai no tālās vietas caur tuneli, ne tikai lokāli.
Otrais posms: pārvietojiet ASA ģenerēto trafiku caur tuneli
Šis ir solis, ko cilvēki izlaiž. Uz politiku balstīts site-to-site VPN parasti tiek būvēts trafikam starp apakštīkliem, un relay pieprasījumu ģenerē pati ASA. Ja tuneļa piekļuves saraksts un crypto karte atbilst tikai plūsmām no filiāles resursdatora uz servera apakštīklu, relay pakete var nekad neiekļūt tunelī. Pārbaudiet piekļuves sarakstu abos virzienos, ne tikai rindu no filiāles uz serveri.
Pārliecinieties, ka interesējošais trafiks aptver ASA relay avotu un servera adresi un ka arī atgriešanās virziens ir atļauts. Uz VTI balstītā projektā maršrutēšanas lēmums ir vienkāršāks, taču relay atbalsts pār VTI parādījās konkrētā laidienā; ASA DHCP pamācība norāda 9.14(1), tāpēc pārbaudiet attēlu pirms VTI piemēra kopēšanas uz vecāku ierīci.
Ping no ASA uz serveri pats par sevi maz ko pierāda. Tas var izdoties pa citu ceļu, ar citu avota adresi vai saskaņā ar politiku, kurai relay paketes neatbilst.
Trešais posms: izlasiet atbildi un setroute opciju
RFC 2131 norāda, ka serveris sūta atbildi uz adresi giaddr laukā, ja šis lauks nav nulle. Tātad atgriešanās ceļam jābūt maršrutētam uz relay adresi, un tuneļa politikai jāatļauj virziens no servera uz relay. Ja pieprasījums izgāja, bet piedāvājums tā arī neatnāca, te ir jāmeklē.
Pēc tam atšķiriet divas līdzīgi skanošas lietas. Atslēgvārds setroute maina vai pievieno noklusējuma maršrutētāja opciju, ko ASA dod klientam. Tas neinstalē maršrutu uz ASA un neveido VPN politiku. Klients, kas saņem adresi, bet neko nesasniedz, bieži saskaras ar setroute vai tvēruma problēmu, nevis tuneļa problēmu. Pārbaudiet to ar klientu bez statiskas vārtejas un vērojiet, kurš noklusējuma maršrutētājs parādās piedāvājumā.
Izlasiet piedāvājumu no sākuma līdz beigām: piedāvātā adrese, maska, noklusējuma maršrutētājs, DNS un nomas laiks. Pēc tam ļaujiet nomai atjaunoties. Relay, kas nostrādā vienreiz un neizdodas atjaunošanā, parasti saskaras ar tvēruma, nomas vai atgriešanās ceļa problēmu, ko pirmā apmaiņa noslēpa.
Ko es pārbaudu, pirms saku, ka tas ir salabots
Sāciet no klienta un nofiksējiet apraidi, pēc tam pārliecinieties, ka ASA to pārsūtīja ar savu adresi kā giaddr. Tālajā pusē pārliecinieties, ka serveris redzēja šo pieprasījumu un izvēlējās filiālei atbilstošu tvērumu. Atgriežoties filiālē, pārliecinieties, ka klients pieņēma piedāvājumu un sasniedz savu vārteju.
Ja kāds posms ir kluss, pārbaudiet atbilstošo politiku vai maršrutu, nevis pievienojiet vēl vienu relay paziņojumu. Relay konfigurācija parasti jau ir pareiza brīdī, kad kāds eskaluo; mainījusies ir tuneļa politika vai atgriešanās maršruts.
Ierakstiet trīs posmus izmaiņu žurnālā: klienta puses saskarne, VPN politika, kas aptver relay trafiku, un servera atgriešanās maršruts uz giaddr. Tieši šis ieraksts padara nākamās filiāles būvniecību par atkārtojamu darbu, nevis atkļūdošanas sesiju. Tas arī pasaka nākamajam inženierim, kuru komandas izvadi vākt vispirms.