ASA DHCP релесі site-to-site VPN арқылы: қадамдық нұсқаулық
Site-to-site VPN арқылы ASA DHCP релесінің үш кезеңінен өтіңіз: клиент интерфейсі, реле трафигіне арналған туннель саясаты және giaddr-ке жауап.
Реле үш кезеңде жұмыс істейді және тек ортаңғы кезең ғана VPN-нен өтеді. Клиент филиал сегментінде broadcast жібереді, ASA оны DHCP серверіне unicast сұранысқа айналдырады, ал сервер клиентке емес, реле мекенжайына жауап береді. Кезеңдерді осы ретпен өтіңіз, сонда «реле бұзылған» жағдайларының көбі жетіспейтін саясатқа немесе қате оқылған setroute жолына әкеп тіреледі.
Бірінші кезең: релені клиентке қараған интерфейсте қосу
Филиал ASA-да реле клиенттерге қараған интерфейстің қасиеті. Серверді оның қолжетімді интерфейсімен ғаламдық түрде жариялауға болады, немесе маршруттау кестесі шығу жолын таңдауы үшін сол клиентке қараған интерфейстің астында жариялауға болады. Бұл екі нысан бірін-бірі алмастырмайды, ал дұрыс емесін көшіру — нұсқаулықтың алғашқы рет адасатын жері.
Бірдеңе өзгертудің алдында ағымдағы конфигурацияны тексеріңіз: қай интерфейсте реле қосулы, қай сервер нысаны бар және setroute клиент интерфейсіне байланған ба. Егер ASA басқа сегмент үшін DHCP серверін де іске қосса, тоқтап, шектеулер тізімін оқыңыз; сервер мен релені бір құрылғыда бір уақытта қосуға болмайды.
Реле өзінің клиентке қараған мекенжайын шлюз мекенжайы өрісіне қояды. Сервер дәл осы мекенжайға жауап береді, сондықтан ол тек жергілікті емес, туннель арқылы алыс сайттан да қолжетімді болуы керек.
Екінші кезең: ASA жасаған трафикті туннель арқылы өткізу
Бұл — адамдар өткізіп жіберетін қадам. Саясатқа негізделген site-to-site VPN әдетте ішкі желілер арасындағы трафик үшін құрылады, ал реле сұранысын ASA өзі жасайды. Егер туннельдің access list және crypto map тек филиал хостынан сервер ішкі желісіне бағытталған ағындарға сәйкес келсе, реле пакеті туннельге мүлде кірмеуі мүмкін. Access list-ті екі бағытта да тексеріңіз, тек филиалдан серверге жолды емес.
Қызықтыратын трафик ASA релесінің көзін және сервер мекенжайын қамтитынын, қайтару бағытының да рұқсат етілгенін растаңыз. VTI негізіндегі құрылымда маршруттау шешімі қарапайым, бірақ VTI арқылы реле қолдауы белгілі бір шығарылымда келді; ASA DHCP нұсқаулығы 9.14(1) көрсетеді, сондықтан VTI мысалын ескі құрылғыға көшірмес бұрын образды тексеріңіз.
ASA-дан серверге ping өздігінен көп нәрсені дәлелдемейді. Ол басқа жолмен, басқа бастау мекенжайымен немесе реле пакеттері сәйкес келмейтін саясат астында сәтті болуы мүмкін.
Үшінші кезең: жауапты және setroute опциясын оқу
RFC 2131 бұл өріс нөлге тең болмағанда сервер жауабын giaddr ішіндегі мекенжайға жібереді дейді. Сондықтан қайтару жолы реле мекенжайына маршрутталуы керек, ал туннель саясаты серверден релеге бағытты рұқсат етуі керек. Сұраныс өтті, бірақ ұсыныс ешқашан келмесе, қарайтын жер осы.
Содан кейін ұқсас естілетін екі нәрсені ажыратыңыз. setroute кілт сөзі ASA клиентке беретін әдепкі маршрутизатор опциясын өзгертеді немесе қосады. Ол ASA-ға маршрут орнатпайды және VPN саясатын жасамайды. Мекенжай алып, еш жерге жете алмайтын клиентте көбіне setroute немесе scope мәселесі болады, туннель мәселесі емес. Оны статикалық шлюзі жоқ клиентпен сынап, ұсыныста қай әдепкі маршрутизатор шығатынын бақылаңыз.
Ұсынысты басынан аяғына дейін оқыңыз: ұсынылған мекенжай, маска, әдепкі маршрутизатор, DNS және жалдау уақыты. Сосын жалдау жаңартылуына жол беріңіз. Бір рет жұмыс істеп, жаңартуда сәтсіздікке ұшырайтын реле әдетте scope, жалдау немесе қайтару жолы мәселесіне тап болады, оны бірінші алмасу жасырған.
«Түзетілді» демес бұрын нені тексеремін
Клиенттен бастап broadcast-ты ұстап алыңыз, содан кейін ASA оны өз мекенжайымен giaddr ретінде жібергенін растаңыз. Алыс жақта сервер бұл сұранысты көргенін және филиалға сәйкес scope таңдағанын растаңыз. Филиалға оралып, клиент ұсынысты қабылдағанын және өз шлюзіне жететінін растаңыз.
Қайсыбір кезең үнсіз болса, тағы бір реле мәлімдемесін қосудың орнына сәйкес саясатты немесе маршрутты тексеріңіз. Біреу мәселені көтерген кезде реле конфигурациясы әдетте дұрыс болады; өзгергені — туннель саясаты немесе қайтару маршруты.
Үш кезеңді өзгерістер журналына жазыңыз: клиентке қараған интерфейс, реле трафигін қамтитын VPN саясаты және сервердің giaddr-ке қайтару маршруты. Дәл осы жазба келесі филиал құрылысын жөндеу сессиясы емес, қайталанатын жұмысқа айналдырады. Ол сондай-ақ келесі инженерге қай команда шығысын бірінші жинау керегін айтады.