Сервер или клиент: која OpenVPN единица на Pi со двојна улога

На Pi работат два OpenVPN процеси, кој истовремено прима талкачки корисници и стигнува до горен провајдер, и тие речиси ништо не делат освен хардверот. Едниот слуша влезни тунели, другиот ѕвони кон надвор. Секој го чита својот директориум и секој има свој режим на откажување. Рестартирањето на погрешната единица е најчестиот начин на кој поправка на клиентот наместо тоа го разнишува слушателот.

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

Upstream 2.6 доставува две шаблонски единици, [email protected] и [email protected]. Шаблонот за сервер започнува во /etc/openvpn/server и од таму го вчитува %i.conf. Шаблонот за клиент започнува во /etc/openvpn/client. Инстанца со име roaming може да постои на двете места истовремено, како сервер и како клиент, со две неповрзани конфигурации и без врска меѓу нив освен низата.

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

systemctl list-units --type=service 'openvpn-*@*'
systemctl cat [email protected]
systemctl show -p WorkingDirectory -p ExecStart [email protected]

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

Одлучете според насоката на пакетите, не според името на интерфејсот

Серверската инстанца има сокет за слушање и прифаќа врски. Нејзиниот шифриран транспорт е локален влез и локален излез на Pi, додека сообраќајот што го препраќа за корисниците ја следи патеката на препраќање и одговара на друг збир правила. Клиентската инстанца во таа смисла нема слушател: таа ѕвони на партнер, затоа нејзиниот шифриран транспорт е локален излез кон долниот слој.

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

Погледнете ги сокетите пред да теоретизирате. Сервер врзан за udp/1194 покажува сокет за слушање. Клиентот покажува асоцијација со адресата на провајдерот и ништо што слуша.

ss -lunp | grep openvpn
ss -unp state established '( dport = :1194 or sport = :1194 )'

Стандардната рута на едната инстанца може да ги пресретне одговорите на другата

redirect-gateway што го турка горниот клиент инсталира стандардна рута што се натпреварува со сите други на машината, вклучувајќи ги одговорите што серверот ги испраќа до талкачките корисници. OpenVPN прави исклучок за сопствената партнерска адреса за тунелот да остане достапен, но тој исклучок не кажува ништо за телефон на хотелска мрежа.

Симптомот обично е асиметричен. Ракувањето завршува, клиентот пријавува поврзаност, и сообраќајот умира по првиот пакет одговор. Рутирање на политики базирано на извор, или ознака на пакет поставена на серверската инстанца со --mark, ги држи двата тек одвоени; ниту едното само по себе не е целосен збир правила, и двете бараат валидни рути во табелата што ја избираат.

Тестирајте ја локалната одлука, а не состојбата на тунелот, бидејќи јадрото го избира изворот и интерфејсот пред OpenVPN да го види пакетот.

ip route get 203.0.113.44
ip rule show

Рестартирајте една улога и докажете дека другата преживеа

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

Запишете го условот за запирање пред промената: дали губењето на горниот тунел ги блокира талкачките корисници, или се враќа на сопствениот горен линк на Pi? DNS и IPv6 исто така бараат јасен одговор, бидејќи турнат резолвер често живее подолго од рутата што го направила корисен.

systemctl restart [email protected]
systemctl is-active [email protected]
journalctl -u [email protected] -n 20 --no-pager

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