The openSUSE.Asia Summit 2024 is fast approaching, and we’re excited to invite participants from all over the world to join us Nov. 2 and 3 in Tokyo, Japan.

This year promises a diverse range of sessions and activities, with an inclusive Cross-Distro Track featuring collaborations with community members from AlmaLinux, Debian and Ubuntu .

Those who want to provide a talk need to submit either long talk or short talk presentations by August 4. Those speakers needing financial assistance can use the Travel Support Program (TSP), which is aided through donations to the Geeko Foundation. The TSP helps covering travel expenses. Here’s a detailed look at important deadlines for TSP applications and speaker proposals to ensure you don’t miss out on this incredible opportunity.

Travel Support Program (TSP) Schedule

The Travel Support Program is designed to help you join us at the summit. Here’s the timeline you need to follow:

• TSP Application Open: As soon as possible. Don’t wait to apply for travel support.
• Call for Speakers Deadline: August 4. If you’re interested in sharing your knowledge and experience, submit your proposal by this date.
• TSP Application Deadline: August 20. Ensure your application for travel support is completed and submitted by this date. Visit the wiki for more information
• Call for Speakers Notification: Speakers will be notified if their proposal has been accepted toward the end of August.
• TSP Confirmation: Final confirmation of travel support will follow shortly after the speakers’ notifications. Around August 26.

Submitting Your Proposal

The openSUSE.Asia committee is looking for speakers who can bring diverse perspectives and insights related to openSUSE and other Linux distributions. Here are some guidelines and tips to help you submit a strong proposal:

• Topics: We’re interested in a wide range of topics, including but not limited to openSUSE Projects (Leap, Tumbleweed, MicroOS), desktop environments (GNOME, KDE, XFCE), office and graphic applications (LibreOffice, GIMP), cloud and virtualization (Kubernetes, Rancher), and package supply-chain security.
• Non-Technical Topics: Overviews of Open Source technologies, community management, education, and personal experience stories are also welcome.
• Session Types: You can propose long talks (30 minutes plus Q&A) or short talks (15 minutes plus Q&A). Lighting talk sessions will be announced later.

How to Submit: Proposals should be submitted through events.opensuse.org. Make sure your submission is in English, is between 130 to 250 words, and adheres to the openSUSE Conference Code of Conduct. For guidance on writing a strong proposal, refer to our proposal writing guide.

Presentation Requirements: You can present in English or Japanese, but all slides and documents must be in English. Note that pre-recorded videos or video calls are not permitted; you must be present at the venue. For more details, visit events.opensuse.org.

El mejor gestor de imágenes de la Comunidad KDE (y una de las mejores del mercado tanto libre como privado) sigue su desarrollo y me complace anunciar que ha sido lanzada la cuarta actualización de digiKam 8, una nueva versión que incluye un buen número de soluciones de errores y la incorporación de algunas mejoras, como el traductor automático de etiquetas.

Cuarta actualización de digiKam 8, ahora con traductor automático de etiquetas

Tras cinco meses de mantenimiento activo y una larga selección de errores, el equipo de digiKam se enorgullece de presentar la versión 8.4.0 de su gestor de fotos digitales de código abierto.

Esta versión llega con el algunas novedades como el traductor automático de etiquetas, que permite llamar automáticamente a un traductor en línea para que genere las palabras clave correspondientes en los idiomas que prefiera o el nuevo procesador G’MIC para el gestor de colas por lotes, con el que podremos aplicar más de 600 efectos a nuestras fotos de forma masiva.

Como siempre , esta versión viene con una gran lista novedades, aunque en esta ocasión vienen heredadas de las actualizaciones de sus componentes. De esta forma tenemos:

• Actualizado el decodificador interno RAW Libraw a la rolling-release snapshot 2024-07-11. Esto incluye una lista de nuevas cámaras soportadas.
• El conjunto de herramientas DNG de Adobe se ha actualizado a la última versión 1.7.1, que incluye la compatibilidad con la compresión JPEG-XL para reducir el tamaño del contenedor del negativo digital.
• Ahora DigiKam es compatible con la nueva API del kit de herramientas LensFun 0.4 de esta biblioteca prevista para este año.
• QtAVPlayer interno ha sido actualizado a la última rolling-release snapshot 2024-06-16. Para la versión Qt6, el reproductor multimedia es ahora capaz de avanzar vídeo fotograma a fotograma.
• ExifTool ha sido actualizado en todos los paquetes a la última versión 12.88. También la otra biblioteca compartida de metadatos muy importante Exiv2 se ha actualizado a la última versión 0.28.2.

Más información: Digikam

Las novedades de digiKam 8

El pasado 16 de abril, es decir, ayer fue lanzado digiKam 8.0, la nueva versión de uno de los gestores de imágenes más completo que puedes encontrar en el mundo GNU/Linux, e incluso en el mundo privativo.

Este nuevo digiKam ha recibido un intenso trabajo en muchas de sus facetas, no en vano han pasado más de dos años de desarrollo donde se han ido puliendo aspectos que estaban descuidados, que simplemente se habían quedado obsoletos o que deben adaptarse a los tiempos en los que vivimos.

Y es que, en el mundo del Software, y en cualquier otro mundo también, si no se evoluciona te extingues. De esta forma, una pincelada de las novedades que nos ofrece su octava versión estable son las siguientes:

• Mejoras en la traducciones.
• Revisión completa de la versión Windows.

Más información: digiKam

¿Qué es digiKam?

La mejor forma de definir digiKam es buscar como se describe esta aplicación de userbase.kde.org y realizar una pequeña síntesis:

«DigiKam es una aplicación que te permite la importación de fotografías desde  cámaras, creación de álbumes, etiquetado con fechas, temas y otras propiedades, utilidades de búsqueda excelentes y modificación de imágenes en masa.»

La entrada Cuarta actualización de digiKam 8, ahora con traductor automático de etiquetas se publicó primero en KDE Blog.

Hello!

It's been a long time since a news update here. Many things changed, and there are lots of exciting news which have been partially communicated in emails and meetings, but not in much detail. I try to clean up some of the news backlog gathered in a good half of a year with this post.

Data center move¶

With SUSE moving one of their datacenters (the one which hosted the majority of openSUSE infrastructure) to Prague towards the end of 2023, we got the opportunity to not only move our systems along, but also to introduce fundamental changes which would have otherwise been difficult to implement in the existing environment - both for SUSE, and for openSUSE.

SUSE graciously provided us with not only brand new hardware, but also autonomy over what we do with it. Whereas the physical infrastructure in the old location was entirely operated by SUSE, with openSUSE merely having SSH access to the virtual machines, the new setup allows the openSUSE Heroes to fully manage their hypervisors and networking stack. This freedom allows the team to implement new ideas and react to issues with virtual machines without relying on and waiting for SUSE internal support.

Maintenance¶

Of course, lots of freedom comes with lots of responsibility. That makes it even more important for our infrastructure to be stable and easy to maintain - after all, the Heroes team is made of volunteers, of which there aren't many who can be motivated to spend their free time with boring maintenance tasks. Hence we now enforce automatic security updates on all machines using os-update and rebootmgr, with added logic to reduce outages by staggering the package updates on reboots of machines in high availability clusters, and to alert administrators about machines requiring updates which cannot install them on their own, or ones requiring manual reboot intervention.

Automation¶

We already use Salt as an automation and infrastructure as code solution since a long time, but increased the Salt coverage by a large margin. Whereas previously only a comparatively small amount of machine configuration was actively maintained using Salt, now the whole base system (network configuration, repositories, kernel settings, authentication, monitoring, logging, certificates, email, automatic updates) is covered, with a steadily increasing amount of the various machine specific services (not surprisingly, the large amount of services under the opensuse.org umbrella comes with a large amount of applications requiring configuration).
Using the infrastructure as code approach has multiple benefits, some of which are:

• configuration changes are tracked and documented in a Git history
• configuration is unified across all machines
• central deployment of changes is possible
  To fully use those benefits, it is essential to have a large coverage, and to reduce the times one needs to manually visit a machine for changes.

We encourage you to check our Git repositories if you are curious (the salt.git repository is now automatically mirrored to code.opensuse.org and GitHub!):
https://github.com/openSUSE/heroes-salt or https://code.opensuse.org/heroes/salt/tree/production
https://github.com/openSUSE/salt-formulas or https://code.opensuse.org/heroes/salt-formulas/tree/main

Monitoring¶

Monitoring already had an important role in our infrastructure before, but it was time to expand it further. The setup which had its center in our old data center, and was based on Nagios and Icinga, served us very well - but after working with it for some time, I gathered the following concerns:

• the server configuration was not managed by Salt, and there was no existing Salt formula community around it
• lots of checks are executed on machines through a central agent which runs as root
• single failure domain
• often the need for custom check scripts to cover new applications

The data center move broke the existing setup, which finally answered my question about whether to refactor or whether to build something new.
After evaluating multiple solutions, including Nagios again, Munin and Zabbix, the choice eventually fell to a stack with Prometheus at its heart. Not only do I have existing experience with Prometheus, but also did I value:

• configuration of all server and client components is either through environment variables, or YAML files - perfect for integration into a code based infrastructure without lots of custom templating
• existing Salt formulas
• each service being monitored is equipped with a dedicated metrics exporter - this for one keeps other services actively monitored if one exporter breaks, but more importantly it allows for deep privilege separation, as most monitoring checks can be performed with only a small set of permissions
• a large amount of applications, especially ones providing web services, which we run plenty of, have built-in support for serving Prometheus compatible metrics - those allow for extremely easy integration with no need to install or write custom monitoring checks or "translation" tools
• plenty of existing community supported exporters for applications which do not provide built-in Prometheus metrics - the configuration of them is usually standardized, making RPM packaging and deployment easy
• easy to add custom checks to collect metrics covered by neither of the above

Already a large amount of additional metrics from various services which were not monitored before are gathered using the new setup. For most we already implemented alerting to notice odd behavior early, and added visualization dashboards with graphs - of course because they are pretty, but also to make spotting anomalies at a glance easier.

The alerting rules which are made of PromQL expression can be found in the previously linked repositories, under salt/files/prometheus/alerts/. Currently, we split alerts based on their severity into either IRC (#opensuse-admin-alerts - still a bit experimental), email, or dashboard receivers.

The alerting dashboard (using Karma) - currently only reachable if connected to the openSUSE Heroes VPN:
https://alerts.infra.opensuse.org/

The visualization dashboards in Grafana - accessible to everyone:
https://monitor.opensuse.org/grafana/.

Our monitoring posture is on a good track, but there is still a lot of work to do to cover more services, fine tune alerts, and to update the internal documentation and response.

Security and internal authentication¶

Previously we used a FreeIPA based LDAP setup for authentication of Heroes to internal services and machines.
We did not use the majority of features FreeIPA offered, and had noone wanting to maintain a machine not running openSUSE anymore - with Kanidm experience in the team, the decision what to migrate to was easy.

In the process, we replaced the sssd installations on all machines with kanidm-unixd, and globally enforced public key based authentications for SSH. Not only is the setup simpler and well maintained, we also found improvements with credential caching, allowing login even throughout potential network issues on a host.

VPN¶

Gateway to all of our internal openSUSE infrastructure is a OpenVPN setup. We improved its security by switching to the current best practices for compression.

Closing words¶

Of course, there have been various other changes, some of which being too small to cover here, some of which simply forgotten about. You will either find out about them in future news posts, or by inspecting our commit and ticket histories.

Have fun!

Veamos cómo utilizar systemd en GNU/Linux para hacer que se ejecute un script al apagar nuestro equipo

En un artículo anterior compartí cómo hacer que se ejecutara un script al iniciar o cerrar el escritorio Plasma:

• https://victorhckinthefreeworld.com/2024/04/02/ejecutar-scripts-al-inicio-o-cierre-de-sesion-en-plasma-6-de-kde/

Pero en mi caso, en un equipo remoto que tenía configurada esa opción, no se estaba ejecuando el script ya que como estaba conectado mediante ssh, apagaba el equipo con el comando poweroff o shutdown desde otro equipo remoto.

Para que siempre se ejecute el script, decidí buscar cómo hacerlo mediante systemd en GNU/Linux.

Ejemplo

Partamos de la premisa que tenemos un script en la siguiente ruta: /home/usuario/Scripts/mi_script.sh Cambia en tu caso, el nombre de usuario, carpeta donde está ubicado y el nombre del script. El script debe tener permisos de ejecución. Ya sabes chmod +x mi-script

Crear el servicio en systemd

Ahora vamos a crear un servicio nuevo para systemd que será el que le indique qué queremos ejecutar y cuando hacerlo. Para ello como root, creamos el siguiente archivo que en mi caso le he llamado antes-apagado.service en la siguiente ruta: vim /etc/systemd/system/antes-apagado.service

Y dentro del archivo pegamos lo siguiente y guardamos el equipo. No olvides cambiar lo necesario en tu caso:

[Unit]
Description=Ejecuta un script antes de apagar el equipo
DefaultDependencies=no
Before=shutdown.target

[Service]
Type=oneshot
ExecStart=/home/usuario/Scripts/mi-script.sh
TimeoutStartSec=0

[Install]
WantedBy=shutdown.target

Siguiendo como root, ejecutamos lo siguiente para reiniciar los servicios de systemd systemctl daemon-reload

Y lo habilitamos para que esté disponible para el próximo apagado: systemctl enable antes-apagado.service

La próxima vez que apaguemos el sistema systemd ejecutará el servicio recién creado que ejecutará nuestro script.

Añadir que se ejecute al reiniciar

Quizás queremos que nuestro script se ejecute no solo al apagar nuestro equipo, si no también al reiniciarlo. Para ello modificaremos el servicio de systemd anterior modificando en el apartado [Unit] la línea de Before y la sustituiremos por esta: Before=shutdown.target reboot.target

Ejecutar un script al iniciar el sistema

También podemos, mediante systemd, hacer que se ejecute el script al inicio del sistema una vez que todos lo servicios de systemd se han arrancado. Para ello tenemos que en vez del servicio anterior, crearemos en la misma ruta otro servicio con el siguiente contenido:

[Unit]
Description=Ejecutar un script al inicio después de que se hayan cargado todos los servicios
After=default.target

[Service]
Type=simple
RemainAfterExit=yes
ExecStart=/home/usuario/Scripts/script-inicio.sh
TimeoutStartSec=0

[Install]
WantedBy=default.target

De manera similar al caso anterior, reiniciamos los servicios y habilitamos el servicio recién creado.

Espero que te resulte útil a ti lector o lectora que recala por el blog, y a mi yo del futuro cuando lo necesite

Me congratula presentaros el episodio Comunitario de KDE Express, titulado «Komunidad con Ivan GJ» donde David Marzal entrevista a Ivan GJ, una de las recientes incorporaciones de KDE España que ha llegado con fuerza colaborando con este blog y realizando vídeos de calidad para sus canales de Peertube y Youtube como ya hemos presentado en esta bitácora.

Komunidad con Ivan GJ en KDE Express

Comenté hace ya bastante tiempo que había nacido KDE Express, un audio con noticias y la actualidad de la Comunidad KDE y del Software Libre con un formato breve (menos de 30 minutos) que complementan los que ya generaba la Comunidad de KDE España, aunque ahora estamos tomándonos un tiempo de respiro por diversos motivos, con sus ya veteranos Vídeo-Podcast que todavía podéis encontrar en Archive.org, Youtube, Ivoox, Spotify y Apple Podcast.

De esta forma, a lo largo de estos más de 30 episodios, promovidos principalmente por David Marzal, nos han contado un poco de todo: noticias, proyectos, eventos, etc., convirtiéndose (al menos para mi) uno de los podcast favoritos que me suelo encontrar en mi reproductor audio.

En esta ocasión cambia de formato ya vuelve el formato Comunitario del podcast. En palabras de David:

Vuelven por fin los episodios de comunidad, en esta ocasión contamos con una de las últimas incorporaciones a la Asociación KDE España.

Hablamos con Iván, sobre como llegó al Software Libre y a KDE, su camino por la divulgación en YT y su nueva etapa enfocada en la cultura y SL.

• Enlaces de las cosas mencionadas en el episodio:
  • Mastodon: https://mastodon.social/@ivangj
  • Peertube: https://fediverse.tv/a/ivangj/
  • Web: https://ivangj.xyz/
  • Repoductor Haruna : https://haruna.kde.org/

¡Seguidle que tiene muchas cosas que contar!

Agradecimientos: Jorge Lama por su asistencia, consejo, apoyo y edición de audio en este episodio.

Y, como siempre, os dejo aquí el audio para que lo podáis disfrutar.

Por cierto, también podéis encontrarlos en Telegram: https://t.me/KDEexpress

La entrada Komunidad con Ivan GJ en KDE Express se publicó primero en KDE Blog.

告知しています通り、openSUSE.Asia Summit 2024 Tokyo を2024年11月2日(土)、3日(日) に麻布台ヒルズの株式会社SHIFTさんで開催します。
openSUSE.Asia Summit はアジア地域の openSUSE コミュニティ（貢献者、ユーザー）が一堂に集まり、交流し、楽しむイベントです。

openSUSE.Asia Summit 2024ではopenSUSE以外にも，Dockerなどのコンテナ，DevOps，日本語IMEなどのLinux Desktop，オープンソースのオフィススイートであるLibreOfficeやセキュリティについてなど幅広いトークを予定しています。また、AlmaLinux、Debian、Ubuntuなどの主要ディストリビューションの講演があるCross Distro Trackもあります。

この openSUSE.Asia Summit 2024 Tokyoにて、学生ボランティアを募集しています。
アジアのオープンソース関係者と交流するまたとない機会です！

学生ボランティアには素敵な特典をご用意。

• イベントTシャツ
• 懇親会11/2(土)のご招待

交通費について

• 関東近郊：交通費実費。上限目安：四日間で4000円（これを超える場合はご相談下さい）
• 宿泊を伴う場合：交通費、宿泊費実費ないし一部。ご相談下さい。（8/20までに予定する交通費、宿泊費をご連絡ください）

ボランティアの仕事

• 会場の準備
• 来場者受付
• スピーカーのサポート（マイク、タイムキーパーなど）
• 4日(月祝)のツアーのサポート

希望するセッションには基本的に参加できます。英語が出来なくても問題ありません。また、発表者として発表されることを推奨します。

詳細

• 日時
  • 2024年11月1日（金）17:00-19:00
  • 2024年11月2日（土）8:00-20:00
  • 2024年11月3日（日）9:00-20:00
  • 2024年11月4日（月祝）※ツアー（詳細未定）
• ※全時間ではありません。
• 会場：麻布台ヒルズ 株式会社SHIFT
• 募集条件: 少なくとも土曜日に参加できること（土曜日に参加できない場合は応相談）

お手伝いいただける方は、以下の情報をopensuse-asia-24-contact@googlegroups.comまでお送りください。

• 氏名：
• 氏名よみがな：
• 所属(大学名/学部名)：
• Tシャツサイズ（XS / S / M / L / XL）：
• メールアドレス：
• 参加日：
• 必要な交通費：

イベント詳細については以下をご覧ください。

• イベントページ：https://events.opensuse.org/conferences/oSAS24

沢山のご応募をお待ちしています。明日のOSSを担うのは君だ！

De ser un evento muy delimitado en formato ha pasado a ser uno más flexible, aunque no os engañéis, 24H24L es uno de os mejore podcast de GNU/Linux que os podéis llevar a vuestro podcaster. Os presento el episodio que fue publicado recientemente dedicado a las Herramientas de Linux para red, nuevo audio de 24H24L, un proyecto de José Jiménez en el que no solo se explicarán esa herramientas sino que también se hablará de financiación, IA y otros temas.

Herramientas de Linux para red, nuevo podcast de 24H24L

Os invito a que disfrutéis del siguiente vídeo donde Samuel, del podcast Yo Virtualizador , y Felipe, de la newsletter weareDMNTRs le explican a José Jiménez, promotor del proyecto 24H24L, algunas herramientas de Linux para la gestiones de la red.

De esta forma, a lo largo de la hora y media que dura el podcast se hablará de herramientas como Asbru, Trsz-sh, Skim o Warp Terminal, entre otros temas, sin olvidar de uno de los temas recurrentes de estos proyectos como son la financiación.

Aprovecho para poner algunos enlaces de interés para poder disfrutar de esta iniciativa que ya lleva mucho tiempo promocionando el Software Libre y en la que espero poder participar pronto.

• 24H24L en Anchor
• 24H24L en YouTube
• 24H24L en PeerTube

Más información: 24H24L

La entrada Herramientas de Linux para red, nuevo podcast de 24H24L se publicó primero en KDE Blog.

これまで自宅用の VPN はルーターの機能の L2TP/IPSec を使っていました。しかしながら、Android 12から L2TP/IPSec が使えなくなったり、もともと接続元のネットワーク環境次第で接続できないという制約もあり、VPN を WireGuard に乗り換えることにしました。

WireGuard は Linux カーネルに組み込まれている VPN プロトコルで、特にセキュリティとパフォーマンスを売りにしています。

構成はこんな感じです。VPN 接続用の IP アドレスは固定です。

• 自宅側
  • ルーター
    • ヤマハのダイナミックDNSサービスで IP アドレスを引ける
  • VPNサーバー（ファイルサーバー）
    • openSUSE Leap 15.5
    • LAN側アドレス (eth1): 192.168.10.2（インターネットには直接つながってない）
    • VPN側アドレス: 192.168.2.1
    • ポート: 51820
• リモート側
  • Android 14 スマートフォン
    • VPN側アドレス: 192.168.2.2
  • Android 13 タブレット
    • VPN側アドレス: 192.168.2.3
  • openSUSE Leap 15.6 ノートPC
    • VPN側アドレス: 192.168.2.4

秘密鍵・公開鍵を作成する

VPN に参加するサーバーとクライアントそれぞれの秘密鍵・公開鍵を作ります。openSUSE が動いている PC で以下のコマンドでそれぞれ作成します。

wg genkey | tee privatekey | wg pubkey > pubkey

privatekey と pubkey に秘密鍵と公開鍵それぞれが保存されます。合計3回実行することになります。

VPNサーバー側の設定

今回の説明の範囲外ですが、ルーターでポートフォワーディングの設定をしておきましょう。必要なポートはUDP 51820です。192.168.10.2 に転送するようにしておきます。

まずは VPN サーバー自体のネットワーク設定です。WireGuard そのものにはプロトコル上、サーバーとクライアントという関係はなく、どちらもサーバーでありクライアントなシンプルな構成です。後は WireGuard をどのような用途で使うかによって設定が変わってくるため、WireGuard の説明を見るときに、用途を意識してドキュメントを見ないと混乱するので注意が必要です。

今回は自宅で常時起動しているファイルサーバーを VPN サーバーの役割を持たせて、自宅のネットワークにつなぎたい端末からこのサーバーに繋いで使用することにします。ここからはいつもの Arch Wiki に感謝ですが、「特定のユースケース: VPN サーバー」 を見ることで、この用途の設定方法がわかります。

はじめに、転送とファイアウォールの設定です。YaST でやってしまいましょう。

• YaST > 「ネットワーク設定」 > 「ルーティング」を開き、「IPv4 転送を有効にする」をON
• YaST > 「ファイアウォール」 で使用しているゾーンで「ポート」 > 「UDP ポート」 に 51820 を追加

次に、WireGuard の設定をしていきます。wg コマンドで設定する方法もあるのですが、設定ファイルを直接作成するのが手っ取り早いです。

/etc/wireguard/wg0.conf

[Interface]
PrivateKey = VPNサーバーの秘密鍵
Address = 192.168.2.1/24
ListenPort = 51820
MTU = 1420

PostUp = iptables -A FORWARD -i %i -j ACCEPT; iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -t nat -D POSTROUTING -o eth1 -j MASQUERADE

[Peer]
PublicKey = Android 14 スマートフォンの公開鍵
AllowedIPs = 192.168.2.2/32 

[Peer]
PublicKey = Android 13 タブレットの公開鍵
AllowedIPs = 192.168.2.3/32

[Peer]
PublicKey = openSUSE Leap 15.6 ノートPCの公開鍵
AllowedIPs = 192.168.2.4/32

この設定から、VPN 用のインタフェース wg0 を作成します。Systemd を使用して、起動時に WireGuard インタフェースを立ち上げる便利スクリプトの wg-quick を使います。

systemctl enable --now wg-quick@wg0

クライアントの設定―openSUSE Leap 15.6

NetworkManager の接続の追加に WireGuard があり、これで接続できます。入力する必要の値は

• openSUSE Leap 15.6 ノートPC 用の秘密鍵
• ピア（接続相手: つまり、この場合サーバー）の設定
  • VPNサーバーの公開鍵
  • Allowed IPs (VPN を通して通信するアドレスレンジ)
    • LANとVPNのアドレスレンジ: 192.168.10.0/24, 192.168.2.0/24
    • 自宅LAN経由でインターネットに出たい場合は 0.0.0.0/0 を指定して、全部を VPN 経由にすることも可能

クライアントの設定―Android スマートフォン

Wireguard の接続アプリは Play Store から入手できます。NetworkManager と同様に手入力でもよいのですが、以下のようなファイルを PC 上で作成して QR コード化して送ることもできます。

[Interface]
Address = 192.168.2.3/24
PrivateKey = Android端末の秘密鍵
DNS = 192.168.10.1
MTU = 1420

[Peer]
PublicKey = VPNサーバーの公開鍵
AllowedIPs = 192.168.10.0/24, 192.168.2.0/24
Endpoint = 外からアクセスできるルーターのホスト名:51820

ファイル名を android-phone.conf とすると、QR コードは次のようにして作成できます。

qrencode -t ansiutf8  < android-phone.conf

qr コマンドでも同じことができます。