Skip to content

By Тодор in LZ5AE (LZ1ETE)

Начало 7 Май 2022 17:00, край 8 Май 2022 17:00.
Успях да направя скромно включване в контеста от една затънтена полянка в родопите. В общи линии всички познати, лесно достъпни и сгодни местенца за излизане около Пловдив бяха заети от туристи, та се наложи да пообикалям, докато си намеря свободна полянка в района между с. Марково и с. Гълъбово (KN22IA). Открити посоки – само север и северозапад.
Техниката, с която работих:

  • Yeasu FT-817nd.
  • Външен компресор DYC-8×7 2.0
  • 4 елементна яги антена за 2м.
  • Мачта от триножник за студийно осветление.
  • 10м RG58 кабел до антената.
  • 12V/7Ah батерия CSB на поне 4г. но все още способна.


Успях да се чуя с приятели, с които не съм се чувал и виждал от много време и в крайна сметка записах в лога си 5 връзки с български станции. Макар, че чувах и станции от Сърбия, с моите 4-5W и не особено фокусирана антена, нямаше как да ги стигна.
За следващия контест планирам нова двубандова антена, а може и да споделя процеса по изработката ѝ.

Правилата за провеждане на радиолюбителски УКВ състезания може да прочетете тук.

73,
de LZ1ETE

Tags: , , , ,

By Тодор in Linux

Въпрос за 1-ви клас: Знаете ли как се конфигурира SSH автентикация базирана на ключове?
Въпрос за 2-ри клас: Знаете ли какво е обратен (reverse) SSH тунел?

Ситуация: Имаме *nix сървър, който е разположен зад NAT или има толкова лош firewall, че не разрешава никакви входящи връзки. А ние искаме да се свържем с него „от вън“ (през Интернет). А може сървъра да е в мрежата на някой глупав Интернет доставчик, чиито DHCP lease е неприлично кратък и адресите се сменят…

Решение 1: Инсталираме OpenVPN клиент и го свързваме с наш VPN сървър, който е публикуван и достъпен в Интернет. После по изградения VPN канал се свързваме към супер секретния или с неизвестен ИП адрес отдалечен хост.

Решение 2: Стартиране на обратен SSH тунел към наш сървър в Интернет. Ето това решение разглеждам в текущата статия.

Най-краткия пример е следния:
На отдалечения хост изпълняваме следната команда:

ssh -R 42001:localhost:22 tunnel@ssh.kamenitza.org

Това ще изгради SSH връзка до адрес ssh.kamenitza.org и през тази връзка ще тунелира трафика от 127.0.0.1:42001 на сървъра ssh.kamenitza.org към 127.0.0.1:22 на динамичния хост с неизвестно ИП. Т.е, ако искаме да се свържем с отдалечената машина е необходимо в SSH сървъра да извикаме:

ssh 127.0.0.1:42001

Супер лесно и готино. Обаче как да си осигурим постоянното стартиране на SSH тунела от отдалечения хост?

Създаваме си демон, който ще се стартира автоматично сам и ще осигурява SSH връзката.

Генерираме ключовете за автентикация на клиента:

mkdir -p /etc/tunnel
ssh-keygen -qN "" -f /etc/tunnel/id_rsa

Създаваме файл /etc/systemd/system/ssht.service със следното съдържание:

[Unit]
Description=Reverse SSH tunnel
Wants=network-online.target
After=network-online.target
StartLimitIntervalSec=0

[Service]
Type=simple
Environment=REVERSE_PORT=42001
Environment=SSH_SERVER=ssh.kamenitza.org
Environment=SSH_PORT=22
Environment=SSH_USER=worm
Environment=CLIENT_SSH_PORT=22

ExecStart=/usr/bin/ssh -qNn \
  -o ServerAliveInterval=30 \
  -o ServerAliveCountMax=3 \
  -o ExitOnForwardFailure=yes \
  -o StrictHostKeyChecking=no \
  -o UserKnownHostsFile=/dev/null \
  -i /etc/${SSH_USER}/id_rsa \
  -R ${REVERSE_PORT}:localhost:${CLIENT_SSH_PORT} \
  ${SSH_USER}@${SSH_SERVER} -p ${SSH_PORT}
Restart=always
RestartSec=60

[Install]
WantedBy=multi-user.target

Създаване на потребителя на сървъра:

useradd -m -s /bin/true tunnel
mkdir -p ~tunnel/.ssh
chown -R tunnel:tunnel ~tunnel/.ssh
chmod 700 ~tunnel/.ssh

Поставяме съдържанието на /etc/tunnel/id_rsa.pub от клиента в ~tunnel/.ssh/authorized_keys на сървъра.
Настройката на правата е задължителна:
chmod 600 ~tunnel/.ssh/authorized_keys

И вече можем да активираме демона на отдалечената машина:

systemctl daemon-reload
systemctl enable ssht
systemctl start ssht

Ако всичко е наред, би трябвало сега от SSH сървъра да можем да се закачим за отдалечения хост ето така:

ssh localhost:42001

Tags: , , ,

By Тодор in Linux

# virsh start my_virtual_pc
error: Failed to start domain my_virtual_pc
error: internal error: process exited while connecting to monitor: failed to initialize KVM: Cannot allocate memory

Това е гадно, нали? Ето причината:

# free -h
              total        used        free      shared  buff/cache   available
Mem:            62G         45G        558M        2.9G         16G         13G
Swap:           31G        2.8G         29G

И това е нормално – свободната памет трябва да бъде ползвана. В случая, 16ГБ от оперативната памет са отишли за кеширане на каквото е намерил за добре линукса. Но ние искаме да си пуснем виртуалната машина! И не искаме да спираме никой от процесите, които заемат повечеко RAM. Най-лесно е да вземем да разчистим всичкия тоя кеш буфер:

# echo 3 > /proc/sys/vm/drop_caches

Бърза проверка:

# free -h
              total        used        free      shared  buff/cache   available
Mem:            62G         46G         12G        2.8G        4.3G         12G
Swap:           31G        2.8G         29G

Tags: , , , ,

By Тодор in Windows

Паролата за отдалечен достъп до Уиндоус (Windows Remote Desktop) компютър може да се съхрани в RDP файла, който бихме могли да ползваме, като шорткът. Така няма да бъдат искани никакви креденшъли при влизане. Добавя се следния ред:

password 51:b:encrypted-password

Паролате е кодирана с инструментчето cryptRDP5. Изпълнява се в командния ред:

> cryptRDP5.exe mega-password
01000000D08C9DDF0115D1118C7A00C04FC297EB010...

By Тодор in Linux

Интернет е пълен, даже направо фрашкан с адреси бълващи спам, сканиращи ботове, заразени устройства и какви ли още не безполезни генератори на трафик.
Аз не бих ги пуснал до мой сървър. Лесен начин да се оттървем поне от познатите такива съм публикувал тук.
Това е прост баш скрипт, който изтегля публичен списък с лоши адреси и създава iptables плравила, които да издропят трафика идващ от тях.

By Тодор in Linux

Ubuntu Server 18. Уж модула е инсталиран, но в логовете се виждат ей такива грешки:
# warning: pcre:/etc/postfix/domains.pcre is unavailable. unsupported dictionary type: pcre

Все пак проверяваме:

# postconf -m | grep pcre
pcre

Ръчно събитието може да се повтори ето така:

# postmap -q foo pcre:/etc/postfix/domains.pcre
postmap: warning: unsupported dictionary type: pcre (/usr/lib/postfix/dict_pcre.so: No such file or directory)
postmap: fatal: unsupported dictionary type: pcre

И тук вече се изяснява картинката. Библиотеката е инсталирана, просто файла е с друго име.
Поправяме конфигурацията ей така:

# sed -i 's/\/dict_pcre/\/postfix-pcre/g' /etc/postfix/dynamicmaps.cf

Tags: , , , , , ,

By Тодор in Linux

Наложи ми се да копирам големи файлове от уиндоус към линукс през SSH. Обикновнео ползвам WinSCP за подобни дейности. За малки файлове или отдалечено редактиране е приемливо и удобно, но когато стане дума за много гигабайти – по-скоро не. Проблемът му е, че дори при достатъчно бърза връзка, скоростта на копиране пак се колебае между 1 и 3 МВ/с. Ползвайки последната към момента версия.
В чудене и безброй проби с подреждания и размествания на крипто алгоритмите на клиента и на сървъра, в крайна сметка стигнах до най-бързото решение (за мен). Уловката е, че е линукс-линукс. В уиндоус вероятно с cygwin може да се измисли нещо, но нямам доказателства.
Самото копиране:
tar -zcvf - /path | ssh user@1.2.3.4 "cd /tmp && tar -zxvf -"
Това ще вземе директорията /path и ще я излее на 1.2.3.4 в /tmp. Явно да се прекара през тарване и зипване дава положителни резултати.

Tags: , , , , , ,

By Тодор in Linux, Windows

ldapmodify е основен инстурмент с който могат да се редактират обекти в една активна директория (АД) посредством *nix среда.

За едно сравнително популярно действие, като смяна на парола, обаче нещата не са толкова лесни, или поне на пръв поглед не са. Смяната на паролата в LDIF формат изглежда така:

dn: CN=Testi Testev,OU=Users,OU=Accounts,DC=corp,DC=local
changetype: modify
replace: userPassword
userPassword: SlivovSladoled

Kомандата се изпълнява успешно и редактира съответния атрибут, но ефект от това няма. Т.е. никаква парола не сме сменили.
Оказва се, че в Windows Active Directory, userPassword полето по подразбиране не е разрешено. Разрешаването му е лесно с ADSI Edit:


Стойността на dsHeuristics трябва да е точно 000000001 (не 1). След промяната е необходима и актуализация на схемата:

И сега вече нещата се случват! Пример:
LDAPTLS_REQCERT=never ldapmodify -D 'CN=Admin,OU=Admins,DC=corp,DC=local' -w AdminPwd -p 389 -ZZ -x -h 192.168.1.1 -f ldif.txt

  • Admin е администраторския акаунт, който има права да редактира чужди пароли.
  • LDAPTLS_REQCERT=never е необходимо, поради тази грешка: TLS: peer cert untrusted or revoked (0x42).
  • -ZZ -x са необходими, за да се закачим към ЛДАП сървъра по сигурен/криптиран канал. Иначе действието не е позволено.
  • 192.168.1.1 е домейн контролера.
  • ldif.txt са ЛДАП командите подобно на тези по-горе в статията.
  • *ADSI Edit е страхотен инструмент, с който, ако не се внимава, може напълно и завинаги да бъде сасипана една Активна Директория.

    Tags: , , , , , , , ,

    By Тодор in Linux

    С конфигурацията на Carbon по подразбиране, Whisper база данни файловете пазят информация само за последните 24часа. Промяната на този период е лесно да се направи в конфигурацията на Carbon:
    /etc/carbon/storage-schemas.conf

    
    [default]
    pattern = .*
    retentions = 1m:30d,15m:10y
    

    Важна е стойността на pattern – в примера ще се отнася за всички броячи, но могат да се правят и шаблони по имената им. Другото важно е, че тези промени се отансят само за новосъздадени броячи. Всички вече създадени бази данни с броячи, трябва да се актуализират ръчно:
    
    # find /var/lib/graphite/whisper/ -type f -name '*.wsp' -exec whisper-resize --nobackup {} 1m:30d 15m:10y \;
    # chown _graphite:_graphite /var/lib/graphite/whisper -R
    # systemctl restart carbon-cache
    

    На кратко:

    • Преравя всички WSP файлове, които са в директорията по подразбиране (ако не са там, да се види в carbon.conf къде са) и променя схемата им за съхранение.
    • Понеже всички редактирани фйалове са собственост на root, ги връща обратно на потребителя _graphite.
    • Рестарт на carbon-cache демона.

    Tags: , , , , , , , , ,

    By Тодор in Uncategorized

    Както всички телефони, и моят се препълни със снимки и клипове.
    Включвам го с УСБ кабел към компютъра и започвам да копирам. По най-стандартния уиндоусовски начин – копи от телефона, пасте на диска на компютъра. Да, ама върви със скорост все едно през телефонна линия го правя. Беше късно, не ми се занимаваше, реших да го оставя да се изкопира през нощта. На другия ден поглеждам какво става и за около 10 часа беше изкопирало 9%. А данните общо са около 30ГБ. Надушвам конспирация! Нарочно са го направили така, за да не могат хората да си копират файловете, а да им ползват облаците. Прекратих го. Обмислях варианта просто да извадя картата памет от телефона и да си взема файловете директно от нея, но исках да опитам и още нещо.

    Дали няма да мога да си помогна с Android Debug Bridge?

    Необходимо е да се активира „Отстраняване на УСБ грешки“, което се намира в „Настройки > Опции на програмиста“. Менюто „Опции на програмиста“ по принцип е скрито, и за да се покаже е необходимо първо да отворим „Всичко за телефона“ и да натискаме бързо 10-15 пъти върху „Номер на версията“.

    ADB e разархивиран някъде на компютъра. Пускам командния ред (cmd) и отивам в директорията на ADB.
    Първо влизам в телефона и проверявам къде точно са снимките или файловете, които ще копирам:

    >adb shell
    HWVNS-H:/ $ df -h
    Filesystem                          Size  Used Avail Use% Mounted on
    rootfs                              1.3G   14M  1.3G   2% /
    tmpfs                               1.3G  544K  1.3G   1% /dev
    tmpfs                               1.3G     0  1.3G   0% /mnt
    none                                1.3G     0  1.3G   0% /sys/fs/cgroup
    /dev/block/dm-0                     1.8G  1.8G   17M  100% /system
    /dev/block/dm-1                     580M  394M  173M  70% /vendor
    /dev/block/dm-2                     182M  101M   77M  57% /product
    /dev/block/dm-3                      27M  412K   26M   2% /version
    /dev/block/dm-4                     182M   95M   83M  54% /cust
    /dev/block/bootdevice/by-name/cache 248M  164K  243M   1% /cache
    tmpfs                               1.3G     0  1.3G   0% /storage
    /dev/block/dm-5                      10G  8.9G  1.4G  87% /data
    /data/media                          10G  8.9G  1.3G  87% /storage/emulated
    /dev/fuse                            30G   28G  2.0G  94% /storage/4308-131B

    32GB-товата ми SD-карта е ясна – /storage/4308-131B.

    Още малко ориентиране:

    $ cd /storage/4308-131B
    HWVNS-H:/storage/4308-131B $ ls
    Android DCIM Download Huawei HuaweiBackup LOST.DIR Pictures backup z

    Директорията със снимките е DCIM. Излизам от телефона:
    exit

    Копиране:
    adb pull /storage/4308-131B/DCIM/Camera c:\todor\

    След няколко секунди става ясно, че скоростта на копиране е коренно различна. Сега е сравнимо с нормална USB2 флашка. 30те ми ГБ се изкопираха за по-малко от час.

    Има и противоположна команда push, с която пък могат да бъдат копирани файлове в другата посока – към телефона.

    Наздраве!

    Tags: , , , , , , , , , , , ,

    By Тодор in Cisco, Linux

    Маршрутизаторите и комутаторите също имат нужда от архивиране! Не че това ще направи подмяната на изгорял рутер удоволствие, но ще е значително по-лесно. А и решението е почти контрол на версиите – с един commit на ден, което помага и при синдрома „вчера работеше“.
    Най-лесния начин, за който се сещам е автоматична бекъпвачка с Ansible.

    Попълваме инвентара в текстов файл горе-долу по тоя пример (ios-inventory):

    [all:vars]
    backup_dest="/ios_backups/"
    date_stamp="{{ ansible_date_time.year }}{{ ansible_date_time.month }}{{ ansible_date_time.day }}-{{ ansible_date_time.hour }}{{ ansible_date_time.minute }}"
    ansible_connection=local
    ansible_user=ansible
    ansible_password=na-baba-mi-parolata
    ansible_become_method=enable
    
    [sw1]
    192.168.0.254
    [sw2]
    192.168.0.253
    [sw3]
    192.168.0.252

    После създаваме следния ямълски плейбук (playbook.yml):

    ---
    - name: Cisco IOS backup job
      hosts: all
      gather_facts: yes
      strategy: free
    
      tasks:
        - name: Collecting remote facts
          ios_facts:
            gather_subset:
              - all
        - name: Create backup root folder
          file:
            path: "{{ backup_dest }}"
            state: directory
          run_once: yes
        - name: Create backup device folder
          file:
            path: "{{ backup_dest }}{{ ansible_net_hostname }}"
            state: directory
          run_once: yes
        - name: Saving configuration to file
          copy:
            content: "{{ ansible_net_config }}"
            dest: "{{ backup_dest }}{{ ansible_net_hostname }}/{{ inventory_hostname }}-{{ date_stamp }}.txt"

    Изпълняваме ето така:
    ansible-playbook -i ios-inventory playbook.yml

    Добавяйки абсолютните пътища до файловете, тоя ред го мушваме в крон за ежедневно изпълнение и с това връзваме гащите.
    Ако имената и паролите за достъп до техниката са различни, то, където е необходимо, променливите с името и паролата ги слагаме на реда с ИП адреса, разделени с интервал.
    Ретеншън може да се поддържа с logrotate.

    Сега може да си пиете бирата все едно мрежата е архивирана 🙂
    Наздраве!

    Tags: , , , ,

    By Тодор in Linux

    Изходни данни за ситуацията

    • Трябва да се инсталира линукс сървър.
    • Нямаме фиизчески достъп до сървъра.
    • Сървъра няма out-of-band управление (iLO, LOM, IPMI и т.н.).
    • Сървъра разполага с ethernet връзка към Интернет.
    • На място (при сървъра) има човек, който може да окаже някакво съдействие. Ще го наречем бай Иван.

    План за действие

    • Ще направим имидж (ISO), който ще изпратим на бай Иван, за да го качи на флашка и да зареди сървъра от него.
    • От флашката ще се заредят достатъчно „неща“, които да ни осигурят отдалечен и сигурен достъп до машината, за да продължим инсталацията.

    Изпълнение

    Ще използваме minimal образ на Ubuntu 20.04 LTS, защото е изключително малък и ще бъде лесно да бъде изпратен на бай Иван.
    Образа е наличен тук.
    Отваряме ISO-то и редактираме txt.cfg. Той би трябвало да съдържа следните редове:

    label install
    menu label ^Install
    menu default
    kernel linux
    append vga=788 initrd=initrd.gz --- quiet

    Редактираме последният ред (всичко е на един ред):
    append vga=788 initrd=initrd.gz console-setup/layoutcode=us locale=en_US.UTF-8 keyboard-configuration/layoutcode=us languagechooser/language-name=English countrychooser/shortlist=BG localechooser/supported-locales=en_US.UTF-8 hostname=ubuntuserver domain=local interface=auto url=https://kamenitza.org/files/preseed.cfg debian-installer/allow_unauthenticated_ssl=true ipv6.disable=1 ---

    Нещата, които този ред върши са сравнително ясни и самообясняващи се. По-интересни са

    • interface=auto – Автоматична настройка на мрежовия интерфейс (DHCP).
    • url=https://kamenitza.org/files/preseed.cfg – Съдържа предврителен избор на опции от инсталацията.

    Ако в мрежата няма DHCP сървър и IP-то трябва да се настрои ръчно, interface=autо се замества със следните примерни параметри:
    netcfg/get_ipaddress=192.168.150.111 netcfg/get_netmask=255.255.255.0 netcfg/get_gateway=192.168.150.1 netcfg/get_nameservers=8.8.8.8 netcfg/disable_dhcp=true

    За редакция на ISO файл в Уиндоус няма особено работещи безплатни програмчета. Аз ползвах WinISO, което в триал/демо режим върши работа за малки образи.
    По наша преценка се прави бутваща USB флашка (с Rufus) или CD или DVD.
    Горещо препоръчвам ползването на възможно най-пълен preseed.cfg, за да се елиминира ръчния труд при повторно изпълнение на задачата:

    d-i preseed/early_command                   string anna-install network-console
    d-i debian-installer/locale                 string en_US.UTF-8
    d-i localechooser/supported-locales         multiselect en_US.UTF-8
    d-i console-setup/ask_detect                boolean false
    d-i keyboard-configuration/layoutcode       string en
    d-i anna/choose_modules                     string network-console
    d-i network-console/authorized_keys_url     string https://kamenitza.org/files/ssh-key.txt
    d-i mirror/country                          string Bulgaria
    d-i mirror/http/hostname                    string bg.archive.ubuntu.com
    d-i mirror/http/mirror                      select bg.archive.ubuntu.com
    d-i mirror/http/proxy                       string
    d-i passwd/user-fullname                    string Todor Kandev
    d-i passwd/username                         string tkandev
    d-i passwd/user-password-crypted            password $5$ceFBePtE$n0S0.mW1tQQUYH4RPfshNIWd/vilV3E2NhBkUWk/yd0
    d-i clock-setup/utc                         boolean false
    d-i time/zone                               string Europe/Sofia
    d-i clock-setup/ntp                         boolean true
    d-i clock-setup/ntp-server                  string bg.pool.ntp.org
    d-i pkgsel/update-policy                    select none
    d-i apt-setup/services-select               none
    d-i apt-setup/universe                      boolean true
    d-i tasksel/first multiselect               standard system utilities, OpenSSH server
    d-i preseed/late_command                    string \
        in-target mkdir -p /home/tkandev/.ssh; \
        echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIN1hQH5HHB8U2PUbUn7nwYUHm0jdz3URoFdYZY1+QSVk kandev-v2" > /target/home/tkandev/.ssh/authorized_keys; \
        in-target chown tkandev:tkandev /home/tkandev/.ssh -R; \
        in-target sed -i s/#PasswordAuthentication\ yes/PasswordAuthentication\ no/g /etc/ssh/sshd_config; \
        apt-install mc net-tools
    d-i finish-install/reboot_in_progress       note

    Опциите са достатъчно говорящи и самообясняващи се. Основна опция тук е network-console/authorized_keys_url. Представлява URL адрес до SSH ключа, който ще се ползва за автентикация при инсталацията. Друго интересно е създаването на потребител, задаването на парола, добавянето на SSH ключ, включването на този потребител в sudoers и забраняването за ползване на пароли при влизане през SSH. Паролата на потребителя се генерира ето така:
    mkpasswd -m sha-256

    Сега бай Иван трябва да буутне сървъра с нашия имидж и да избере опцията за инсталация по подразбиране. След няколко минути всичко спира на следния екран:
    Linux network instal
    Може да си знаем адреса, а може и бай Иван да ни го изпрати по някакъв начин. Инструкциите са ясни. Свързваме се с дадения IP адрес по SSH с потребител installer, като се автентикираме с личния си ключ. Довършваме инсталацията с всичко, което липсва от preseed фйла.

    Наздраве! 🙂

    Tags: , , , , ,

    By Тодор in Uncategorized

    Ползвал съм собственоръчно направени НАС-ове, било то полу-готови с Freenas, изградени от стандартна Linux дистрибуция или напълно готови хардуерни решения, за които съм писал и преди. В крайна сметка най-доволен останах от Synology. Не защото е перфектно, а защото има най-малко проблеми и бъгове.
    Разбира се че е пълно с бъгове! Пакетът му с основни приложения е абсолютен качамак! Нито снимките можеш да си архивираш по някакъв полезен начин, нито файловете. Но целта на поста не е да правя ревю на продукта, а да споделя един особено дразнещ и неприятен дефект.

    Притежавам един от малките модели – DS218+. Машинката е закачена за APC UPS, има и комуникационен кабел между нея и UPS-a, за да ѝ е по-ясно каква е ситуацията с тока. Включена е 24/7, като е разрешено единствено да гаси дисковете, ако не се ползват известно време.
    Няколко пъти намирам НАС-а загасен. Ама все едно съм му натиснал копчето и се е изключил. А още по-неприятното е, че не може и да се включи. След натискане на бутона, светва, развърта вентилатора, но не развърта дисковете и след 10сек се изключва отново. После пак натискам бутона и стискам палци. И така понякога от 5-тия, понякога от 10-тия опит, вземе, че развърти дисковете и тръгне.

    Актуализирах софтуера. Сканирах за грешки. Проверявах захранващия блок. Не открих проблем.
    Единствената закономерност, която открих е, че, ако извадя единия или и двата диска, след като се е самозагасил, и натисна копчето, зарежда веднага. Не открих в Интернет някой да е писал за дискова несъвместимост, а и ползвам доста стандартни дискове – 4TB HGST (HDN726040ALE614).
    Все още не се предавам и не звъня в гаранционния сервиз за рекламация!

    След поредната проверка на конфигурацията и търсене на скрити детайли или каквито и да е улики за проблема из интерфейса на устройството се натъквам на следната опция:
    DS218+ Problem

    Естествено това беше включено. Даже кой би си помислил, че такава екстра няма да си я има бай-дизайн вградена и ще се налага ръчно да я пускаш и спираш!?

    Ами изключих я и проблемите изчезнаха! Вече повече от година не се е самоизключвало.

    Наздраве!

    Tags: , , , , , , , , , , , , , , ,

    By Тодор in Linux

    Натъкнах се на неочаквана мотика при комуникацията от контейнер към самия себе си, но през публичния му адрес.

    Очаквано тук трябва да се случат някои гимнастики с iptables, за да има двупосочна транслиране, известно още като nat reflection или hairpin nat. Да, обаче пак не работи!

    В крайна сметка се оказва, че Docker си прави всичко сам, ама само, ако си поискаме 🙂

    Вградената userland proxy услуга трябва да бъде спряна, за да се получи това, което желаем, а именно, ако контейнера ни е с адрес 172.17.0.2, който от Интернет е достъпен на 70.80.90.100, да можем от самия контейнер да се свържем към адреса 70.80.90.100 и това да бъде правилно транслирано от хоста обратно към контейнера.

    На кратко:

    Създаваме файл /etc/docker/daemon.json със следното съдържание:

    {
    "userland-proxy": false
    }

    И рестартираме докер услугата:
    
    systemctl restart docker
    

    Дали се е получило можем да видим от следния параметър на ядрото на ОС съдържаща контейнерите (трябва да е със стойност 1):
    
    # sysctl net.ipv4.conf.docker0.route_localnet
    net.ipv4.conf.docker0.route_localnet = 1
    

    Tags: , , , , , , , , , , , ,