Зашто OpenVPN клијенти промашују IPsec селекторе мрежног пролаза

Пошаљите ping са пролаза ка хосту иза удаљеног IPsec тунела и он чисто одговара, па тунел изгледа здраво и тикет иде даље. Затим повезан клијент проба исти хост и не добија ништа. Тај 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 подешава исти одредиште кроз поставке приватне мреже или правила приступа инсталиране верзије, при чему се рутирани или преведени режим бира намерно. Уређивање генерисаних ланаца заштитног зида уместо конфигурације која их поседује је пут којим радна инсталација постаје немогућа за репродукцију.

После повезивања читајте рутирајућу табелу клијента, а не намеру сервера. Рута која покрива само базен значи да гурање никада није стигло, а подразумевана рута кроз тунел је шира од овог захтева и изненадиће вас касније. Проверите маску и префикс, јер /25 гурнут као /24 шаље саобраћај суседних адреса путем који га не може носити. Затим потврдите да је клијент за то одредиште изабрао интерфејс тунела.

Нека селектори укључују клијентски базен

За рутирани приступ који чува адресе клијената, IPsec политика мора да штити саобраћај између базена и удаљеног префикса. Селектори написани за сопствену LAN мрежу пролаза пуштају ping и одбацују захтев клијента, и то је управо та асиметрија која је започела ово истраживање.

Прегледајте договорену политику и конфигурисане предлоге, на пример са ipsec statusall на strongSwan-у или еквивалентном статусном командом за вашу имплементацију. Код IPsec-а заснованог на политикама обична рута може да показује на физички интерфејс док се одговарајући саобраћај и даље шифрује, па недостатак тунелског уређаја ништа не доказује. Упоредите парове селектора са базеном и префиксом које сте записали.

Општи изворни NAT на пролазу такође може да поквари поклапање. Ако правило masquerade препише извор клијента пре провере политике, пакет више не изгледа као селектор који сте написали. То је један од разлога зашто је широко правило masquerade лоша поправка за други VPN: мења то која се политика примењује и коју адресу удаљена страна бележи. Изузмите саобраћај који намеравате да рутирате, или га намерно преведите и ажурирајте селекторе.

Намерно изаберите рутирање или превођење

Рутирање држи адресу клијента видљивом удаљеној страни, па удаљени логови и правила по извору остају смислени, и захтева да удаљени пролаз зна повратни пут до базена. Превођење крије базен иза једне адресе, што уклања проблем повратне руте и уништава идентитет сваког клијента.

Изаберите један дизајн и запишите га, јер оба траже различите селекторе и другачији редослед заштитног зида. Половично примењен masquerade остаје између њих и не задовољава ниједан. Записани избор је и оно што следећем инжењеру омогућава да разликује грешку од намерне одлуке.

Затворите петљу на прослеђивању и одговору

Пролаз мора да прослеђује протокол и одредиште које имате на уму, што значи укључено IP прослеђивање и ланац прослеђивања који дозвољава пар. Затим удаљена страна мора да шаље одговоре назад IPsec путем, и то је одлука о рутирању на њиховом пролазу, не на вашем. Обе половине су обична конфигурација и обе лако остају недовршене. Тестирајте их одвојено да се правило прослеђивања које недостаје не замени за покварен тунел.

Проверите једним стварним захтевом од клијента ка апликацији, гледајући како пролази кроз интерфејс OpenVPN, одлуку IPsec и удаљени хост. Прегледајте одговор као одвојено посматрање, јер захтев који стигне и одговор који се никада не врати изгледају исто са места клијента. Један праћени захтев вреди више од било ког броја ping-ова са пролаза.

Држите овлашћење за одредиште уским док тестирате, и потврдите да клијент без правила не може да стигне до услуге. Инсталирана рута и успостављена асоцијација нису исто што и додељен приступ.