role: user

type: text

text:
<timestamp>Tuesday, May 12, 2026, 4:07 PM (UTC+3)</timestamp>
<user_query>
/bin/sh -c '/usr/bin/systemctl --user daemon-reload && /usr/bin/systemctl --user reset-failed vpn-up.service >/dev/null 2>&1 || true; /usr/bin/systemctl --user restart vpn-up.service'

у меня есть вот десктоп ссылка, запускаю корп впн так
но у меня траффик к Keyckloak гонится через Интернет, надо через ВПН. Исправь.
Например https://employee.auth.lemanapro.ru/admin/employee/console/
</user_query>


role: assistant

text:
Понял задачу: нужно, чтобы `employee.auth.lemanapro.ru` ходил через корпоративный VPN, а не в обычный интернет. Сейчас проверю, как устроен `vpn-up.service` и какие маршруты/скрипты он применяет, затем внесу точечное исправление в unit/скрипт.

**Evaluating terminal options**

I’m considering using `ls` to check the terminals and possibly reading files with ReadFile, since head isn’t allowed. I might explore using Glob+ReadFile to collect information without starting long processes. But since running commands could impact the user’s VPN, I might need to provide guidance on fixing this without executing commands. The user asked for a fix, so we might modify the desktop file or inspect the service unit for automation when the VPN is up.

Shell

description: List terminal state files

description: Show vpn-up user service unit

command: systemctl --user status vpn-up.service --no-pager

description: Check vpn-up service status


text:
Нашел, что сервис запускает `openconnect-sso` через скрипт `vpnc-wrapper.sh`; вероятнее всего именно там настраивается split-tunnel и сейчас не добавлен маршрут до Keycloak. Сейчас посмотрю оба скрипта и добавлю route по домену через VPN-интерфейс.

**Inspecting scripts for VPN**

I'm focusing on the vpn-up script and vpnc-wrapper.sh, as they probably control the routes. I plan to use ReadFile for file operations to get a closer look at each file. The paths are in the home directory, so I'll read both scripts. I also want to ensure that I provide some intermediary comments as I go through the process to keep things clear. This should help guide my updates effectively!


description: Show per-link DNS routing domains

description: Resolve Keycloak host via current DNS

command: ip route get $(getent ahostsv4 employee.auth.lemanapro.ru | awk 'NR==1{print $1}')

description: Check route used for Keycloak IP


text: Причина подтвердилась: сейчас через VPN роутится только DNS-домен `~lmru.tech`, а `lemanapro.ru` резолвится через обычный Wi‑Fi DNS, поэтому и трафик идет мимо туннеля. Сейчас правлю `vpnc-wrapper.sh`, чтобы он добавлял оба routing-domain (`~lmru.tech` и `~lemanapro.ru`) при подключении.

ApplyPatch

input:
*** Begin Patch
*** Update File: /home/ruslanpi/.local/bin/vpnc-wrapper.sh
@@
 VPNSCRIPT="/etc/vpnc/vpnc-script"
-VPN_DNS_DOMAIN="${VPN_DNS_DOMAIN:-lmru.tech}"
+VPN_DNS_DOMAINS="${VPN_DNS_DOMAINS:-lmru.tech lemanapro.ru}"
@@
 case "${reason:-}" in
   connect|reconnect)
-    if [ -n "$VPN_DNS_DOMAIN" ] && [ -n "${TUNDEV:-}" ]; then
+    if [ -n "$VPN_DNS_DOMAINS" ] && [ -n "${TUNDEV:-}" ]; then
       IFINDEX="$(cat "/sys/class/net/$TUNDEV/ifindex" 2>/dev/null || true)"
-      echo "VPN_DNS_DOMAIN=$VPN_DNS_DOMAIN IFINDEX=$IFINDEX CISCO_DEF_DOMAIN=${CISCO_DEF_DOMAIN:-} CISCO_SPLIT_DNS=${CISCO_SPLIT_DNS:-} INTERNAL_IP4_DNS=${INTERNAL_IP4_DNS:-} INTERNAL_IP6_DNS=${INTERNAL_IP6_DNS:-}"
+      echo "VPN_DNS_DOMAINS=$VPN_DNS_DOMAINS IFINDEX=$IFINDEX CISCO_DEF_DOMAIN=${CISCO_DEF_DOMAIN:-} CISCO_SPLIT_DNS=${CISCO_SPLIT_DNS:-} INTERNAL_IP4_DNS=${INTERNAL_IP4_DNS:-} INTERNAL_IP6_DNS=${INTERNAL_IP6_DNS:-}"
       dns_servers="$(printf "%s %s" "${INTERNAL_IP4_DNS:-}" "${INTERNAL_IP6_DNS:-}" | tr ',' ' ')"
       base_domains=""
       if [ -n "${CISCO_DEF_DOMAIN:-}" ]; then
         base_domains="$base_domains $CISCO_DEF_DOMAIN"
@@
       if [ -n "${CISCO_SPLIT_DNS:-}" ]; then
         base_domains="$base_domains $(echo "$CISCO_SPLIT_DNS" | tr ',' ' ')"
       fi
-      # add routing domain for lmru.tech without dropping existing ones
-      domain_args="$base_domains ~$VPN_DNS_DOMAIN"
+      # add custom routing domains without dropping existing ones
+      custom_domain_args=""
+      for domain in $VPN_DNS_DOMAINS; do
+        custom_domain_args="$custom_domain_args ~$domain"
+      done
+      domain_args="$base_domains$custom_domain_args"
       if [ -n "$dns_servers" ]; then
         if [ -n "$IFINDEX" ]; then
           /usr/bin/resolvectl dns "$IFINDEX" $dns_servers || true
*** End Patch


text:
Скрипт обновил. Перезапускаю VPN-сервис и проверяю, что домен `employee.auth.lemanapro.ru` теперь резолвится/маршрутизируется через `tun0`.

**Restarting the service**

I need to make sure that the executable remains unchanged. I think it's time to restart the service using the user's command. A daemon reload might not be necessary for a script change, so I’ll just focus on restarting the service. Additionally, I should verify the domain and route at this point, ensuring everything is updated properly. I’ll send out an update once I can confirm that everything is working smoothly!

Shell

command: /usr/bin/systemctl --user restart vpn-up.service

description: Restart vpn-up user service

description: Check routing domains after restart

command: sleep 2 && resolvectl flush-caches && resolvectl query employee.auth.lemanapro.ru

description: Re-resolve Keycloak hostname after update


text:
**Checking connection status**

It looks like my connection might be having some trouble. The Wi-Fi’s active, but there could be an issue with the VPN not being up yet due to authentication. I think the OpenConnect SSO might need a browser for user action, and that step might not be finished. I really should check the status and logs, maybe run `systemctl status` and `journalctl -f`. Let’s see what that reveals!

command: systemctl --user status vpn-up.service --no-pager

description: Check vpn-up service after restart

description: Inspect DNS config on tun0 link

description: Verify tun0 interface state


description: Verify wrapper script permissions


text:
Исправил на уровне VPN-скрипта: теперь для split-DNS добавляются **оба домена** — `lmru.tech` и `lemanapro.ru`, чтобы `employee.auth.lemanapro.ru` резолвился через DNS в туннеле, а не через внешний интернет.

Что изменено:
- Файл: `/home/ruslanpi/.local/bin/vpnc-wrapper.sh`
- Было: один routing-domain `~lmru.tech`
- Стало: список routing-domain из переменной `VPN_DNS_DOMAINS` (по умолчанию `lmru.tech lemanapro.ru`)
- На connect/reconnect скрипт формирует и применяет через `resolvectl`:
  - существующие корпоративные домены от VPN
  - плюс `~lmru.tech` и `~lemanapro.ru`

Я перезапустил `vpn-up.service`, но сейчас сессия в стадии логина (openconnect-sso ждет завершения авторизации), поэтому `tun`-интерфейс еще не поднялся.

Проверь после завершения входа:
```bash
resolvectl domain
resolvectl flush-caches
resolvectl query employee.auth.lemanapro.ru
ip route get $(getent ahostsv4 employee.auth.lemanapro.ru | awk 'NR==1{print $1}')
```

Ожидаемо:
- в `resolvectl domain` на VPN-интерфейсе есть `~lemanapro.ru`
- `resolvectl query ...` показывает `link: tun...`, а не `wlp...`/`enp...`

Если после логина все еще пойдет не через VPN — добавлю в этот же скрипт принудительный `/32` route для хоста (как fallback).

**Verifying DNS routes**

I’m thinking about adding a DNS route that sends requests to the corporate DNS, which should return the internal address. I also need to mention restarting the system and the openconnect-sso login window being ready. Once that’s complete, everything should work. Should I run ReadLints? Hmm, that's not relevant since it's a non-workspace file and script, so I’ll skip that. Now I need to ensure we keep everything concise while also crafting a final version that includes the changes and verifies the steps.