ASA DHCP релеси site-to-site VPN аркылуу: кадам боюнча жетекчилик
Site-to-site VPN аркылуу ASA DHCP релесинин үч баскычын өтүңүз: клиент интерфейси, реле трафиги үчүн туннел саясаты жана giaddr дарегине жооп.
Реле үч баскычта иштейт жана VPN аркылуу ортодогу баскыч гана өтөт. Клиент филиал сегментинде broadcast жиберет, ASA аны DHCP серверине unicast сурамга айландырат, ал эми сервер клиентке эмес, реле дарегине жооп берет. Баскычтарды ушул тартипте өтүңүз, ошондо «реле бузулган» учурлардын көбү жетишпеген саясатка же туура эмес окулган setroute сабына алып келет.
Биринчи баскыч: релени клиентке караган интерфейсте күйгүзүү
Филиалдын ASAсында реле клиенттерге караган интерфейстин касиети. Серверди анын жеткиликтүү интерфейси менен глобалдык түрдө жарыялоого болот, же маршруттоо таблицасы чыгууну тандашы үчүн ошол клиентке караган интерфейстин астында жарыялоого болот. Бул эки форма бири-бирин алмаштырбайт, ал эми туура эмесин көчүрүү — жетекчиликтин биринчи жолу адашканы.
Бир нерсени өзгөртүүдөн мурун азыркы конфигурацияны текшериңиз: кайсы интерфейсте реле күйүк, кайсы сервер формасы бар жана setroute клиент интерфейсине байланганбы. Эгер ASA башка сегмент үчүн DHCP серверин да иштетсе, токтоп, чектөөлөр тизмесин окуңуз; сервер менен релени бир түзмөктө экиге чогуу күйгүзүүгө болбойт.
Реле өзүнүн клиентке караган дарегин gateway дарегинин талаасына коёт. Сервер дал ушул дарекке жооп берет, ошондуктан ал жергиликтүү гана эмес, туннел аркылуу алыскы сайттан да жеткиликтүү болушу керек.
Экинчи баскыч: 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 дарегине кайтарым маршруту. Дал ушул жазуу кийинки филиал курулушун жөндөө сессиясы эмес, кайталануучу ишке айландырат. Ал ошондой эле кийинки инженерге кайсы команда чыгымын биринчи чогултууну айтат.