diff --git a/raspberry-and-orange-pi/k3s.md b/raspberry-and-orange-pi/k3s.md
index 3a06484..e1bbb5b 100644
--- a/raspberry-and-orange-pi/k3s.md
+++ b/raspberry-and-orange-pi/k3s.md
@@ -619,9 +619,33 @@ sudo k3s kubectl get nodes
 Получим, например:
 ```text
 NAME         STATUS   ROLES                       AGE     VERSION
-opi5plus-1   Ready    control-plane,etcd,master   5d4h    v1.31.5+k3s1
-opi5plus-2   Ready    control-plane,etcd,master   8d      v1.31.5+k3s1
-opi5plus-3   Ready    control-plane,etcd,master   7d2h    v1.31.5+k3s1
+opi5plus-1   Ready    control-plane,etcd,master   1d4h    v1.31.5+k3s1
+opi5plus-2   Ready    control-plane,etcd,master   1d      v1.31.5+k3s1
+opi5plus-3   Ready    control-plane,etcd,master   1d2h    v1.31.5+k3s1
 rpi3b        Ready    <none>                      25h     v1.31.6+k3s1
-vps-sw-eye   Ready    <none>                      7h35m   v1.31.6+k3s1
-```
\ No newline at end of file
+vps-sw-eye   Ready    <none>                      35m     v1.31.6+k3s1
+```
+
+#### Проблема Flannel для внешних узлов
+
+Узлы во внешнем интернете создаются и управляются через Kubernetes API, используя порт `6443/TCP`. Но, для того чтобы
+передавать трафик и данные между узлами k3s использует сетевой плагин **Flannel**. Он встроен в бинарник k3s (в отличие
+от k8s, где Flannel работают как поды) и использует overlay-сеть (`10.42.x.x`). Это внутренняя сеть k3s, VXLAN-туннель
+между всеми узлами кластера (мастерами и воркерами). Flannel использует порт `8472/UDP`.
+
+К сожалению проброс порта `8472` с внешнего хоста в домашнюю сеть через роутер не поможет, так обмен идёт не через TCP-,
+а UDP-порт. Внешний узел отправит пакеты через overlay-сеть Flannel (10.42.x.x) через 8472/UDP к мастеру, но Мастер
+отвечает через свой реальный IP (192.168.1.x), который недоступен напрямую из интернета без обратного проброса или VPN.
+Проброс <PUBLIC_IP>:8472 → <VIP>>:8472 позволяет трафику от внешнего хоста доходить до домашней сети, но ответный
+трафик от мастеров к VPS (например, от <NODE-1>:8472 к <VPS_IP>:8472) не будет проходить, потому что NAT в роутере
+ "односторонний" — он не знает, как маршрутизировать UDP-ответы от мастеров обратно к VPS через интернет.
+
+Таким образом, для управления удаленным узлом нужно чтобы он имел локальный IP-адрес в домашней сети, а не внешний.
+SSH-тоннель с помощью `autossh` и упаковкой UDP-трафика в TCP через `socat` не сработает (а я надеялся). Таким образом 
+"пробросить" Flannel для полноценного подключения удаленного k3s-узла -- VPN-туннель между каждой мастер-нодой на
+удаленный узел. Это вполне рабочия вариант, если удаленные узлы -- полноценные и произвольные хосты. Но в моём 
+случае удаленный узел -- хост на 1 ядро и 1 ГБ ОЗУ. К тому же он на платформе x86_64, а не ARM, а значит ради одного
+узла не стоит заморачиваться с VPN.
+
+Другим вариантом является подключение внутри самих подов на удаленном узле к необходимым сервисам напрямую. Но таким
+образом порты базы данных, менеджеров очередей и т.д. будут доступны из интернета, что небезопасно и в целом плохая идея.