Зошто 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 ја конфигурира истата дестинација преку поставките за приватна мрежа или правила за пристап на инсталираната верзија, со намерно избран рутиран или преведен режим. Уредувањето на генерираните firewall синџири наместо конфигурацијата што ги поседува е патот на кој работна инсталација станува невозможна за репродукција.

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

Нека селекторите го вклучуваат клиентскиот базен

За рутиран пристап што ги зачувува адресите на клиентите, IPsec политиката мора да го заштити сообраќајот помеѓу базенот и далечниот префикс. Селекторите напишани за сопствениот LAN на портата го пуштаат ping-от и го отфрлаат барањето на клиентот, и токму тоа е асиметријата што го започна ова истражување.

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

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

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

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

Изберете еден дизајн и запишете го, бидејќи двете бараат различни селектори и различен редослед на firewall. Половично применет masquerade паѓа меѓу нив и не задоволува ниту еден. Запишаниот избор е и она што му овозможува на следниот инженер да разликува грешка од намерна одлука.

Затворете ја јамката на препраќањето и одговорот

Портата мора да го препраќа протоколот и дестинацијата што ги имате на ум, што значи вклучено IP препраќање и синџир за препраќање што го дозволува парот. Потоа далечната страна мора да ги враќа одговорите по IPsec патеката, и тоа е одлука за рутирање на нивната порта, не на вашата. Двете половини се обична конфигурација, и двете лесно остануваат недовршени. Тестирајте ги одделно за да не се помеша отсутно правило за препраќање со расипан тунел.

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

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