Неге OpenVPN клиенттері шлюздің IPsec селекторларына жетпейді
Шлюзден жасалған ping басқа ағынды дәлелдейді. Клиент пулын итерілген маршрут, IPsec селекторлары, қайта бағыттау тізбегі және жауап жолы арқылы қадағалаңыз.
Шлюзден қашықтағы IPsec туннелінің артындағы хостқа ping жасаңыз, ол таза жауап береді, сондықтан туннель сау көрінеді және билет әрі қарай жылжиды. Сосын қосылған клиент сол хостты талпынып көреді де, ештеңе қайтармайды. Ол ping ешқашан клиент ағынының дәлелі болған емес, өйткені ол шлюздің өз бастау адресімен шығып, басқа IPsec селекторына сәйкес келген. Бұл екі жағдай неге ажырайтынын түсіну — түзетудің басым бөлігі.
Шлюздің ping-і клиентіңіз ешқашан қолданбайтын ағынды тексереді
Қай саясат қолданылатынын бастау адресі шешеді. Шлюзде жасалған пакет жергілікті LAN немесе туннельдің соңғы нүктесінің адресімен шығады, ал оған сәйкес келетін саясат дәл сол жағдай үшін жазылған. Клиент пакеті OpenVPN интерфейсіне клиент пулының адресімен келеді, бұл мүлде басқа селектор.
Сондықтан ақау маршруттау мәселесіне ұқсайды, ал шын мәнінде бұл саясат ауқымының мәселесі. Шлюзден қолжетімділік теңшериктің жұмыс істеп тұрғанын және ұсыныстардың келісілгенін дәлелдейді, ал пулдың қорғалғаны туралы ештеңе дәлелдемейді.
Қолданбаға шынымен қажет қашықтағы префиксті итеріңіз
Қосылған клиенттер үшін 10.8.0.0/24 және қорғалған қашықтағы желі үшін 172.30.239.0/25 көрнекі жұбын алыңыз. Клиентке екінші префикске маршрут керек, шлюздің LAN-ына да, басқа туннель адресіне де емес. Пулға итерілген маршрут клиентті бұл трафикті шлюзге өткізуге мәжбүр етеді. Онсыз пакет сіз жөндеп жатқан саясат шешіміне ешқашан жетпейді.
Итерілген маршруттарды қабылдайтын Community серверінде директива нақты масканы алады: push "route 172.30.239.0 255.255.255.128". Access Server сол тағайындалған жерді орнатылған нұсқаның жеке желі немесе қатынау ережелері параметрлері арқылы баптайды, маршрутталған немесе аударылған режим әдейі таңдалады. Генерацияланған firewall тізбектерін иесі конфигурациясының орнына өңдеу — жұмыс істеп тұрған орнатуды қайта жаңғыртуды мүмкін еместікке апаратын жол.
Қосылғаннан кейін сервердің ниетін емес, клиенттің маршруттау кестесін оқыңыз. Тек пулды қамтитын маршрут итеру келмегенін білдіреді, ал туннель арқылы әдепкі маршрут бұл талаптан кеңірек және кейін сізді таңқалдырады. Масканы да, префиксті де тексеріңіз, өйткені /25-ті /24 ретінде итеру көршілес адрестер трафигін оны көтере алмайтын жолға жібереді. Сосын клиент сол тағайындалған жер үшін туннель интерфейсін таңдағанын растаңыз.
Селекторлар клиент пулын қамтысын
Клиент адрестерін сақтайтын маршрутталған қатынау үшін IPsec саясаты пул мен қашықтағы префикс арасындағы трафикті қорғауы керек. Шлюздің өз LAN-ы үшін жазылған селекторлар ping-ге жол береді де, клиент сұранысын тастайды, және дәл осы асимметрия бұл тексеруді бастаған.
Келісілген саясатты және бапталған ұсыныстарды қараңыз, мысалы strongSwan-да ipsec statusall немесе сіздің іске асыруыңыз үшін баламалы күй командасымен. Саясатқа негізделген IPsec-те қарапайым маршрут физикалық интерфейске көрсетуі мүмкін, ал сәйкес трафик әлі де шифрланады, сондықтан туннель құрылғысының болмауы ештеңе дәлелдемейді. Селектор жұптарын сіз жазып алған пулмен және префикспен салыстырыңыз.
Шлюздегі жалпы бастау-NAT та сәйкестікті бұза алады. Егер masquerade ережесі саясатты тексеруден бұрын клиенттің бастауын қайта жазса, пакет енді сіз жазған селекторға ұқсамайды. Кең masquerade ережесінің екінші VPN үшін нашар түзету болуының бір себебі осы: ол қай саясаттың қолданылатынын және қашықтағы жақ қай адресті тіркейтінін өзгертеді. Маршруттағыңыз келетін трафикті босатыңыз немесе оны әдейі аударып, селекторларды жаңартыңыз.
Маршруттауды немесе аударманы әдейі таңдаңыз
Маршруттау клиент адресін қашықтағы жаққа көрінетін күйде ұстайды, сондықтан қашықтағы журналдар мен әр бастау бойынша ережелер мағыналы болып қалады, және қашықтағы шлюз пулға қайту жолын білуін талап етеді. Аударма пулды бір адрестің артына жасырады, бұл қайту жолы мәселесін жояды және әр клиенттің жеке басын жояды.
Бір дизайн таңдап, оны жазып қойыңыз, өйткені екеуіне түрлі селекторлар мен түрлі firewall реті керек. Жартылай қолданылған masquerade олардың арасында қалып, ешқайсысын қанағаттандырмайды. Жазылған таңдау — келесі инженерге қатені әдейі шешімнен ажыратуға мүмкіндік беретін нәрсе.
Қайта бағыттау мен жауапта циклді жабыңыз
Шлюз сіз көздеген протокол мен тағайындалған жерді қайта бағыттауы керек, бұл қосылған IP қайта бағыттауды және жұпқа рұқсат беретін қайта бағыттау тізбегін білдіреді. Сосын қашықтағы жақ жауаптарды IPsec жолымен кері жіберуі керек, және бұл олардың шлюзіндегі маршруттау шешімі, сіздікі емес. Екі жарты да қарапайым конфигурация, және екеуін де жартылай тастап кету оңай. Оларды бөлек тексеріңіз, сонда жетіспейтін қайта бағыттау ережесі сынған туннель деп қабылданбайды.
Бір нақты клиенттен қолданбаға сұраныспен тексеріңіз, оның OpenVPN интерфейсінен, IPsec шешімінен және қашықтағы хосттан өтуін бақылаңыз. Жауапты бөлек бақылау ретінде қараңыз, өйткені келіп жеткен сұраныс пен ешқашан қайтпайтын жауап клиенттің орнынан бірдей көрінеді. Бір ізі қадағаланған сұраныс шлюзден жасалған қанша ping болса да құндырақ.
Тестілеу кезінде тағайындалған жердің рұқсатын тар ұстаңыз және ережесіз клиент қызметке жете алмайтынын растаңыз. Орнатылған маршрут пен орныққан ассоциация берілген қатынаумен бірдей емес.