OpenVPN сервер и клиент на еден хост: зошто клиентите отпаѓаат

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

Една машина, две улоги и два неспоиви одговори за тоа каде треба да одат одговорите.

Ист базен, два сервера: кој победува

Секоја инстанца на сервер бара своја тунелска подмрежа. Копирање на ред како server 10.8.0.0 255.255.255.0 во втората конфигурација им дава на двете инстанци ист префикс, и исходот е или одбивање да стартува или тивка борба во која клиентите на едниот сервер добиваат адреси што другиот исто така ги смета за свои. Различни UDP порти и различни имиња на уреди не помагаат, бидејќи ниту едно не го допира адресниот простор. Сменете го вториот базен и сменете го насекаде каде рутите го споменуваат.

Наведете што е активно пред да уредувате: ip -4 addr show ги наведува тунелските уреди, ss -lunp ги наведува слушачите, а systemctl list-units ги именува единиците. Еден поглед на тунелските адреси решава дали базените се судираат.

Што додава клиентскиот профил на табелата

Клиентската половина запишува рути веднаш штом се поврзе. redirect-gateway def1 ја дели стандардната рута на 0.0.0.0/1 плус 128.0.0.0/1, двете се рутираат низ новиот уред, заедно со хост рута до далечниот сервер што намерно е прикачена на физичкиот интерфејс. Тоа прикачување постои за тунелот да задржи пат за сопствениот транспорт. Сѐ друго, вклучително одговорите што локалниот сервер ги должи на своите клиенти, сега ја следи новата стандардна рута и излегува низ далечната врска.

Значи вториот судир не е скршен тунел. Тоа е работен тунел на погрешно место во табелата.

Три начини да ги одвоите улогите

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

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

Која од двете инстанци е виновна

Запрете ја клиентската инстанца и повторно тестирајте ги оригиналните клиенти. Веднаш да се врати значи рутирање, а не сервер. Вратете го клиентот и следете еден одговор со ip route get на кој му се дадени и изворна и одредишна адреса, што го покажува патот што јадрото би го избрало, потоа набљудувајте го интерфејсот што пакетите навистина го користат со tcpdump -ni any port 1194. Статусната датотека на серверот, што се пишува на неколку секунди преку директивата status, ги содржи списокот на поврзани клиенти и бајт-бројачите во двете насоки.

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