Защо клиентите на OpenVPN пропускат IPsec селекторите на шлюза

Пуснете ping към хост зад отдалечения IPsec тунел от шлюза и той отговаря чисто, така че тунелът изглежда здрав и тикетът продължава. След това свързан клиент опитва същия хост и не получава нищо. Този ping никога не е бил доказателство за потока на клиента, защото е тръгнал със собствения адрес на източника на шлюза и е съвпаднал с друг IPsec селектор. Разбирането защо двата случая се разминават е по-голямата част от поправката.

Ping-ът от шлюза тества поток, който вашият клиент никога не използва

Адресът на източника решава коя политика се прилага. Пакет, генериран на шлюза, излиза с адрес от локалната му LAN или от крайната точка на тунела, а политиката, която му съответства, е написана точно за този случай. Пакетът на клиента пристига на интерфейса OpenVPN с адрес от клиентския пул, което е напълно различен селектор.

Затова отказът изглежда като проблем с маршрутизацията, докато всъщност е проблем с обхвата на политиката. Достъпността от шлюза доказва, че партньорът е активен и предложенията са договорени, и не доказва нищо за това дали пулът е защитен.

Изпратете отдалечения префикс, който приложението наистина изисква

Вземете илюстративната двойка 10.8.0.0/24 за свързани клиенти и 172.30.239.0/25 за защитената отдалечена мрежа. На клиента му трябва маршрут до втория префикс, а не до локалната мрежа на шлюза и не до някакъв друг адрес на тунела. Маршрутът, изпратен към пула, е това, което кара клиента изобщо да предаде този трафик на шлюза. Без него пакетът никога не достига до решението за политика, което отстранявате.

В сървър Community, който приема изпратени маршрути, директивата приема истинската маска: push "route 172.30.239.0 255.255.255.128". Access Server конфигурира същата дестинация чрез настройките за частна мрежа или правила за достъп на инсталираната версия, като режимът на маршрутизиране или транслация се избира съзнателно. Редактирането на генерирани firewall вериги вместо собствената конфигурация е начинът една работеща инсталация да стане невъзпроизводима.

След свързване четете таблицата за маршрутизация на клиента, а не намерението на сървъра. Маршрут, който покрива само пула, означава, че изпращането не е пристигнало, а маршрут по подразбиране през тунела е по-широк от това изискване и ще ви изненада по-късно. Проверете маската заедно с префикса, защото /25, изпратен като /24, насочва трафика за съседни адреси по път, който не може да го носи. След това потвърдете, че клиентът е избрал интерфейса на тунела за тази дестинация.

Включете клиентския пул в селекторите

За маршрутизиран достъп, който запазва адресите на клиентите, IPsec политиката трябва да защитава трафика между пула и отдалечения префикс. Селекторите, написани за собствената LAN на шлюза, допускат ping-а и отхвърлят заявката на клиента, а това е точно асиметрията, с която започна това разследване.

Проверете договорената политика, както и конфигурираните предложения, например с ipsec statusall на strongSwan или еквивалентната команда за статус за вашата реализация. При IPsec, базиран на политики, обикновеният маршрут може да сочи към физически интерфейс, докато съответстващият трафик все още е криптиран, така че липсващото устройство за тунел не доказва нищо. Сравнете двойките селектори с пула и префикса, които записахте.

Общият source NAT на шлюза също може да наруши съответствието. Ако правило за masquerade пренапише източника на клиента преди проверката на политиката, пакетът вече не изглежда като селектора, който сте написали. Това е една от причините широкото правило за masquerade да е лошо решение за втори VPN: то променя коя политика се прилага и кой адрес записва отдалечената страна. Освободете трафика, който възнамерявате да маршрутизирате, или го транслете съзнателно и актуализирайте селекторите.

Изберете маршрутизация или транслация умишлено

Маршрутизацията запазва адреса на клиента видим за отдалечената страна, така че отдалечените журнали и правилата за отделен източник остават смислени, и изисква отдалеченият шлюз да знае обратния път до пула. Транслацията скрива пула зад един адрес, което премахва проблема с обратния маршрут и унищожава идентичността на всеки клиент.

Изберете един дизайн и го запишете, защото двата се нуждаят от различни селектори и различен ред на firewall. Наполовина приложен masquerade се озовава между тях и не удовлетворява нито един. Записаният избор е и това, което позволява на следващия инженер да различи грешка от съзнателно решение.

Затворете цикъла по препращането и отговора

Шлюзът трябва да препраща протокола и дестинацията, които възнамерявате, което означава включен IP forwarding и верига за препращане, която разрешава двойката. След това отдалечената страна трябва да изпраща отговорите обратно по пътя IPsec, а това е решение за маршрутизация на техния шлюз, не на вашия. И двете половини са обикновена конфигурация и двете лесно остават недовършени. Тествайте ги отделно, за да не се сбърка липсващо правило за препращане със счупен тунел.

Проверете с една реална заявка от клиент към приложение, наблюдавайки как тя преминава през интерфейса OpenVPN, решението на IPsec и отдалечения хост. Разгледайте отговора като отделно наблюдение, защото заявка, която пристига, и отговор, който никога не се връща, изглеждат еднакво от мястото на клиента. Една проследена заявка струва повече от всякакъв брой ping-ове от шлюза.

Дръжте оторизацията за дестинацията тясна, докато тествате, и потвърдете, че клиент без правилото не може да достигне услугата. Инсталиран маршрут плюс установена асоциация не е същото като предоставен достъп.