Еден Pi, два OpenVPN примероци: што чита секоја единица

Избројте ги OpenVPN процесите пред да допрете профил. Pi што прима роаминг корисници и истовремено ѕвони на нагорна услуга извршува два демони, и секој од нив чита конфигурациска датотека избрана од името на примерокот што го внесовте. Пакуваните шаблони потоа на секој демон му доделуваат сопствен работен директориум, сопствена датотека за состојба при извршување и сопствен уред за тунел. Ако оваа поделба ја направите погрешно, ќе поминете вечер менувајќи исправно поставување во датотека што процесот што работи никогаш не ја отвора.

Секое име на примерок избира своја датотека

Во единечните датотеки доставени со OpenVPN 2.6, аргументите за стартување содржат месточувач за примерок што се пополнува со текстот по знакот @. Шаблонот за сервер работи од директориумот за конфигурација на серверот и го решава својот аргумент врз %i.conf таму, додека шаблонот за клиент го прави истото од директориумот за клиент. Значи [email protected] чита admits.conf во директориумот за сервер, а [email protected] чита uplink.conf во директориумот за клиент, и ниту едно од тие имиња нема никакво значење во другиот директориум.

Потврдете го мапирањето на машината наместо да претпоставувате дека пакетот ги задржал стандардните вредности. Drop-in од дистрибуцијата смее целосно да го замени работниот директориум или конфигурацискиот аргумент.

systemctl cat [email protected]
systemctl cat [email protected]

Прочитајте ја линијата WorkingDirectory и конфигурацискиот аргумент во тој излез, бидејќи само овозможената единица одлучува која датотека се вчитува. Drop-in што додава --config на ExecStart победува над шаблонот дури и кога патеката на шаблонот изгледа исправна. Побарајте ги патеките на фрагментот и на drop-in кога сакате да знаете дали е во игра локално препишување. Ако двете улоги се решат на една датотека, имате еден процес што се обидува да биде и сервер и клиент, а подоцнежната опција во таа датотека тивко победува.

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

Шифрираната врска на серверот со секој роаминг корисник се создава на самиот Pi, па неговите надворешни одговори излегуваат низ локалната излезна кука. Врската на клиентот со неговиот нагорен партнер исто така е локално создаден излез, иако достигнува оддалечена мрежа. Препратениот товар е трета категорија, а јадрото го совпаѓа само откако веќе избрало излезен уред за пакетот.

Правило што совпаѓа излезен интерфејс во forward синџир може да дозволи или да отфрли пакет што рутирањето веќе му го доделило на тој интерфејс, но никогаш не го избира интерфејсот. Кога еден домаќин завршува еден тунел и започнува друг, политиката што го испраќа корисничкиот товар во нагорниот тунел и политиката што ги штити сопствените шифрирани одговори на Pi се две одделни одлуки. Тие случајно слетуваат на истата физичка NIC, поради што се мешаат.

Таа разлика објаснува чест половински неуспех. Корисниците се поврзуваат, ракувањето завршува, а нивниот сообраќај сепак излегува на погрешниот пат, бидејќи ракувањето беше локално, а товарот беше forward и само едно од двете беше тестирано.

Увезена рута може да ги проголта одговорите до вашите корисници

Безбедносното поставување на профилот на клиентот одлучува што нагорната страна смее да турка во рутирачката табела на Pi, а широкото пренасочување е опцијата што го претвора работниот домаќин со двојна улога во расипан. Ако турканата рута ги покрива јавните адреси на роаминг корисниците, одговорите што серверот ги создава кон нив може да ја следат новата рута во нагорниот тунел наместо да излезат преку основната мрежа. Луѓето често потврдуваат дека тунелот до давателот сѐ уште работи и застануваат таму, бидејќи тој сообраќај е сопствениот транспорт на тунелот и продолжува да тече додека сѐ друго се однесува погрешно.

Политиката заснована на извор или mark е начинот двете струи да останат одделени. Linux mark опцијата на OpenVPN ги означува сопствените шифрирани пакети на демонот со огнено ѕидно mark, што рутирачко правило потоа може да го испрати во посебна табела. Изворните адреси работат исто толку добро кога надворешните одговори на серверот секогаш излегуваат од една адреса на основната мрежа. И двата пристапи бараат валидни рути во избраната табела и исклучок за endpoint на давателот, инаку самиот тунел повеќе не се крева.

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

ip rule show
ip route get 198.51.100.7 from 192.0.2.10

Потврдете ја поделбата, потоа запрете по една улога

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

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

systemctl stop [email protected]
systemctl status [email protected] --no-pager
ss -lunp | grep openvpn
journalctl -u [email protected] -n 20 --no-pager

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