Сървър или клиент: кой модул OpenVPN на Pi с две роли

Два процеса OpenVPN работят на Pi, който едновременно приема роуминг потребители и достига до доставчик отгоре, и те почти не споделят нищо освен хардуера. Единият слуша за входящи тунели, докато другият се обажда навън. Всеки чете своята директория и всеки има свой режим на отказ. Рестартирането на грешния е най-честият начин едно „поправяне на клиента“ да разклати слушателя вместо това.

Съпоставете името на модула с директорията, която зарежда

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

Приемете промяната само когато три неща са налице едновременно: нова входяща връзка завършва, препратено приложение достига дестинацията си през предвидения изход и двата процеса все още съобщават очаквания си партньор. Ако едно от трите се провали, сте сменили грешната инстанция или грешния маршрут и следващата стъпка е да препрочетете модула, а не да рестартирате нещо друго.