pfSense како VPN сервер и клиент: две патеки, еден рутер

Еден уред може истовремено да гледа во две насоки: роаминг корисниците се поврзуваат навнатре, а истата кутија се поврзува нанадвор кон давател на излез за да може избраниот сообраќај да излезе преку друга мрежа. Вклучувањето на двете услуги трае минути; нивното заедничко постоење бара проект, бидејќи втората улога ја препишува табелата за рутирање на која се потпира првата. Три услови одлучуваат дали распоредот работи, имено дали влезната услуга го задржува својот повратен пат, дали излезниот тунел уште стигнува до својот партнер и дали сообраќајот што сакавте да го пренесете се избира за излезот. Згрешете во едно и добивате два тунели кои и двата известуваат за поврзаност додека меѓу нив не поминува ништо корисно. Проверките подолу го воспоставуваат секој услов по редоследот по кој дефектите обично се појавуваат.

Именувајте ги двете улоги пред да допрете било какво поставување

Запишете четири факти за секој пример: неговиот далечен партнер, материјалот за автентикација, базенот адреси што го дели и мрежите зад него. Двата примера се одделни објекти на уредот и треба да останат одделни и во вашите белешки. Речиси секој збунувачки симптом подоцна доаѓа од мешање на нивните вредности, а два примера што делат еден сет белешки се начинот на кој погрешниот базен завршува во погрешното поле.

На влезната услуга ѝ треба тунелска мрежа што не се преклопува со адресите на излезниот тунел ниту со која било приватна мрежа што уредот ја рутира. Преклопувањето е единствената грешка што истовремено создава симптоми во двете улоги, и далеку е поевтино да се фати на хартија. Споредете ги двата базени и секоја рутирана приватна мрежа на едно место пред да конфигурирате која било од услугите.

Споделениот хардвер не значи споделени акредитиви, а клиентскиот сертификат од базенот за далечински пристап не треба да биде употреблив против давателот на излез. Одделниот материјал го прави и отповикувањето локална одлука наместо настан за целата флота.

Држете ги одговорите на серверот на патеката WAN

Одговорите што самиот уред ги создава се првата жртва на невнимателна стандардна рута. Кога пристигнува инкапсулираниот пакет на роаминг корисник, одговорот е локално настанат сообраќај и мора да излезе преку интерфејсот преку кој дојде тој корисник. Ако излезниот клиент поставил стандардна рута што го фаќа, одговорот влегува во погрешниот тунел и сесијата запира додека услугата уште изгледа здрава.

Нема едно поле за штиклирање што го решава ова, зашто одлуката е за тоа кој сообраќај излезниот клиент смее да го фати. Или не влечете никакви рути и насочете само тоа што ќе го одберете, или влечете рути и додајте ги исклучоците што ги одржуваат сопствените услуги на уредот. Запишете го изборот до примерот, инаку следниот човек ќе го претпостави другиот.

netstat -rn | head -20
pfctl -sr | grep -i vpn
ifconfig | grep -A3 ovpn

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

Не дозволувајте излезниот тунел да ја изеде сопствената крајна точка

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

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

netstat -rn | grep -F '198.51.100.10'
traceroute -n 198.51.100.10

Изберете кои корисници го добиваат излезот

Политиката на извор припаѓа на влезот каде сообраќајот влегува во уредот, затоа изберете го базенот за далечински пристап или потесни идентитети во него. Зачувајте ги приватните одредишта и исклучоците за управување што никогаш не смеат да се испратат на излезот, и ставете ги тие правила пред широкото. Потоа излезната патека бара сопствен превод или рутиран распоред за враќање, што за повеќето проекти значи излезен NAT на излезниот интерфејс што го покрива базенот. Преводот не избира излез; тој само го препишува она што веќе излегло, па правило за NAT на несроден WAN не менува ништо во изборот.

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

openvpn --config user07.ovpn
curl -sS https://ifconfig.me
curl --interface 10.10.10.1 -sS https://intranet.corp.example/health

Првата команда е надворешната врска на роаминг корисникот, и работи кога клиентот известува дека иницијализациската низа е завршена. Втората, пуштена од тој поврзан преносен сметач, треба да ја извести адресата на давателот на излез, а не вашата адреса WAN. Третата работи на уредот, врзана за адреса од базенот, и ја тестира политиката на извор за пренесениот сообраќај без воопшто да вклучи далечен корисник. Ако наместо тоа одговори од WAN, политиката не се совпадна, и никакво уредување на NAT не поправа проблем со избор.

Одлучете што се случува кога излезот откажува

Запишете го однесувањето при дефект пред да се случи: кога излезниот тунел паѓа, дали корисниците се враќаат на обичниот WAN или се блокирани додека излезот не се врати? Двата одговора се одбраниви, и уредот нема да избере наместо вас. Отстранета рута или политика што покажува на мртва порта не создаваат автоматски целосно блокиран резултат. Ако сакате блокирање, политиката мора тоа да го каже експлицитно, и мора да се тестира со одземање на излезот, а не со размислување за него. Ако сакате враќање, објавете го тоа на корисниците, бидејќи сообраќајот што тивко ја зема обичната патека е токму сообраќајот што некој мислел дека е покриен.

Оневозможете го примерот на клиентот, погледнете до што поврзан корисник уште стигнува, па повторно стартувајте го. Барањето што истекува е резултатот на целосно блокирање што го баравте; она што одговара со адресата WAN е враќањето што не го документиравте. Повторете ја проверката за IPv6 и за DNS, бидејќи политика напишана за IPv4 не кажува ништо за сообраќајот AAAA и резолверот што го турка кој било тунел одговара од каде барањето навистина излегува.

pfSsh.php playback svc stop openvpn client 2
curl --max-time 6 -sS https://ifconfig.me
pfSsh.php playback svc start openvpn client 2

Рецептот на Netgate за рутиран OpenVPN покажува како политиката на извор, доделувањето интерфејс и излезниот превод се вклопуваат заедно, а неговиот опфат од локација до локација е делот што не треба да се копира целосно. Она што нема да ви го каже е кој од трите услови погоре вашиот проект веќе го прекршил.