Продолжаю настраивать vds, столкнулся с небольшой проблемой.

Установлен и настроен sslh всё работает, но программы не видят внешний IP соединений.

Например:
➤[Connected 23 Feb 2020, 09:11:18]
Last login: Sun Feb 23 08:13:05 2020 from 127.0.0.1
[nebulosa@vds ~]$

В документации есть инструкция, необходимо применить следующие правила (сразу пишу с поправкой на свои реалии):
sudo iptables -t mangle -N SSLH
sudo iptables -t mangle -A  OUTPUT --protocol tcp --out-interface ens3 --sport 22 --jump SSLH
sudo iptables -t mangle -A OUTPUT --protocol tcp --out-interface ens3 --sport 443 --jump SSLH
sudo iptables -t mangle -A SSLH --jump MARK --set-mark 0x1
sudo iptables -t mangle -A SSLH --jump ACCEPT
sudo ip rule add fwmark 0x1 lookup 100
sudo ip route add local 0.0.0.0/0 dev lo table 100

После применения последней команды - сервер перестаёт принимать соединения.
Подозреваю, что нужно как-то поменять ранг таблицы или прописать как-то ип, но для меня маршрутизация - это тёмный лес, прошу вашей помощи.

Перед всеми действиями конфигурация сервера такая:
$ ip rule list
0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default
$sudo iptables-save
*nat
:PREROUTING ACCEPT [8076:453873]
:INPUT ACCEPT [705:37884]
:OUTPUT ACCEPT [842:52367]
:POSTROUTING ACCEPT [176:9152]
-A POSTROUTING -o ens3 -j MASQUERADE
COMMIT
*filter
:INPUT DROP [7241:407167]
:FORWARD ACCEPT [44705:57871270]
:OUTPUT ACCEPT [288283:318921775]
-A INPUT -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8388 -j ACCEPT
-A INPUT -p udp -m udp --dport 3963 -j ACCEPT
-A INPUT -p udp -m udp --dport 8388 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wg0 -j ACCEPT
COMMIT


$ ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens3: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq state UP group default qlen 1000
    link/ether 52:54:00:02:48:4a brd ff:ff:ff:ff:ff:ff
    inet <my_IP_is_here>/24 brd <IP_gate_is_here> scope global ens3
       valid_lft forever preferred_lft forever
    inet6 fe80::5054:ff:fe02:484a/64 scope link
       valid_lft forever preferred_lft forever
3: tun0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc fq state UNKNOWN group default qlen 100
    link/none
    inet 10.8.0.1/24 brd 10.8.0.255 scope global tun0
       valid_lft forever preferred_lft forever
    inet6 fe80::be2c:6fd5:223b:842e/64 scope link stable-privacy
       valid_lft forever preferred_lft forever
4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.66.66.1/24 scope global wg0
       valid_lft forever preferred_lft forever
    inet6 fd42:42:42::1/64 scope global
       valid_lft forever preferred_lft forever
hoz
Так я не примеряю, а просто ознакомился с различными мнениями. Но.. это не столь важно т.к. своп можно файлом подключить, если что. И отключить, так же.
Ура! Я смог донести мысль)

hoz
Вот моя конфигурация:
  • Процессор: AMD Ryzen 7 1700 Eight-Core Processor 3.00 GHz
  • Материнская плата: ASRock AB350 Gaming K4
  • Память: Corsair 16 Gb DDR4
  • Видеокарта: Gigabyte NVIDIA GeForce GT 710

  • Так что там с диском?) А железки для Линукса вполне себе, чтобы попробовать его в полной красе.
    hoz
    Сверху Partition Type. Как я понимаю Primary, это все разделы, за исключение некоторые типа отдельных поддиректорий пользователей т.е. их домашних каталогов и тд?

    Не углубляясь, всегда выбирайте Primary. Extended нужен когда разделов нужно сделать больше 4-ёх при таблице разделов mbr.

    hoz
    Флаги (Flags) нужно вообще устанавливать?

    Из каких-то важных флагов знаю только boot. Остальные специфичные.
    Не понимаю, правда, как, исследуя пограничные случаи, которые ещё нужно сильно постараться повторить, пытаться получить рабочую конфигурацию для себя?..

    Расскажите уже про ваши железки что-ли.. что там с памятью, процом, диском, а то какие-то разговоры "в пользу бедных".
    Даа... шурум бурум в голове изрядный)

    Самый простой и адекватный способ - это диск никак не делить, тогда не будет никакой дилеммы - сколько на какой раздел сколько надо выделять.Поставьте систему, посмотрите что и сколько занимает, сделайте выводы самостоятельно!

    По моей практике делим диск на: / - 10Гб (из которых по факту будет использоваться 6-7ГБ прям макс макс), /home - всё остальное. Почему так? Всё просто - если я вдруг решу снести систему полностью или вообще сменить дистрибутив на убунту там или ещё какой - форматировать буду только системный диск, а всё что накачано непосильным путём спокойно будет лежать в "домашке" и не нужно будет куда это бекапить и тратить время и прочее прочее. Особенно когда у тебя диск от 1ТБ, забитый любимыми хайрезами вселенной Марвел)

    Плюс ещё в такой схеме, если вдруг на системном диске вдруг закончится место система не встанет колом, т.к. на системном диске есть резерв под пользователя рута (можно будет зайти под ним и почистить например, логи) а на домашке наоборот выделить весь диск под свои нужды (sudo tune2fs -r0 -m0 /dev/sdX1 - раздел с home)

    Еще по наблюдениям - swap, да, под гибернацию, но смысла сейчас в ней особо нет. Даже на ноуте - он в спящий режим уходит. Пару раз добивался того, чтобы система начинала активно использовать swap и сразу ловил три кадра в минуту (винт был обычный, не SSD) :) НЕ ОЧЕНЬ! Поэтому для себя принял решение, что swap не использую, просто ставлю достаточно оперативки, а там святой OOM Killer меня рассудит.

    Если интересно можно включить и swap, причём, опять же, для этого раздел выделять не нужно, давно системы научились подключать его как файл + zswap/zram (ссылка, где в паре абзацев на пальцах объясняют, что и зачем - тык!

    Про бут могу сказать так - выделять нужно столько сколько ядер (разных версий) вам нужно будет одновременно. На одно ядро примерно нужно по 50-55Мб. Насчёт выделения /boot в отдельный раздел - вот конкретные инструкции, т.е. практически не нужен.
    gentux
    Мне сегодня скинули https://youtu.be/OBCBqEC6sS8 чувак кеды под мак неплохо замаскировал.
    Эх, когда то давным-давно в начале времен сидел на кедах, то сделал бы.
    Смысл скриншотов был немного в другом). Для меня арч сейчас исключительно удалённый, на VDS, а с какой системы с ним контактировать - не суть как важно
    Пилю потихоньку...



    Итак, всё решилось! Хотя и не совсем понятно как это связано.

    Смотрел на время загрузки (здесь boottime: alias boottime='sudo systemd-analyze&&sudo systemd-analyze blame --no-pager')
    
    $ boottime
    [sudo] password for nebulosa:
    Startup finished in 2.848s (kernel) + 17.872s (userspace) = 20.721s
    graphical.target reached after 17.872s in userspace
    13.373s systemd-networkd-wait-online.service
    10.320s systemd-random-seed.service
     3.341s systemd-logind.service
     1.659s dev-vda1.device
     1.620s systemd-networkd.service
      979ms systemd-journald.service
      945ms systemd-udevd.service
      915ms systemd-timesyncd.service
      284ms wg-quick@wg0.service
      240ms systemd-udev-trigger.service
      229ms iptables.service
      124ms user@1000.service
       82ms systemd-user-sessions.service
       81ms systemd-journal-flush.service
       62ms systemd-sysctl.service
       42ms systemd-tmpfiles-setup-dev.service
       42ms systemd-remount-fs.service
       41ms var-lib-systemd\x2dswap-swapfc-1.swap
       36ms dev-hugepages.mount
       36ms systemd-tmpfiles-setup.service
       35ms dev-mqueue.mount
       35ms systemd-update-utmp.service
       33ms sys-kernel-debug.mount
       32ms kmod-static-nodes.service
       27ms tmp.mount
       23ms user-runtime-dir@1000.service
       21ms sys-kernel-config.mount
       20ms systemd-tmpfiles-clean.service
       10ms proc-sys-fs-binfmt_misc.mount
    

    Решил уточнить почему сервис systemd-random-seed.service стартует так долго, нашёл данный тред: https://bbs.archlinux.org/viewtopic.php?pid=1863155#p1863155 там жаловались на низкую энтропию, у меня она была ещё меньше 122 вместо 189. Установил пакет, стартовал, активировал, перезагрузился. Всё заработало, энтропия теперь 1919, сеть поднимается.

    ¯\_(ツ)_/¯
    indeviral
    Nebulosa
    достаточно только подключиться через VNC и уже без ввода логина
    Ну так может и проблема тогда в webui или через что вы там vnc используете
    Ммм... не понимаю как это связано..

    Без сети это единственный способ взаимодействовать с хостом. Что вебvnc что другие клиенты делают одно и то же - стучатся на tty1 - пробовал все варианты клиентов какие нашёл.
    eikoninaru
    Nebulosa
    Uptime: 1 day, 13 hours, 51 mins
    за день аптайма обновлял ядро?
    если да перезагрузи машину и попробуй подключиться
    Несколько раз обновлял и перезагружал, конечно же.
    indeviral
    Nebulosa
    При логине на tty сеть поднимается. Значит надо как-то переключить чтобы сеть поднималась сама, автоматически
    Это не проблема
    loginctl enable-linger "ваш user"
    Но такие нюансы больше характерны для пользовательских service, системные так себя вести не должны.
    К сожалению, не помогло.

    
    $ loginctl user-status
    nebulosa (1000)
               Since: Fri 2019-11-22 21:52:08 MSK; 4min 14s ago
               State: active
            Sessions: *2
              Linger: yes
                Unit: user-1000.slice
                      ├─session-2.scope
                      │ ├─6623 sshd: nebulosa [priv]
                      │ ├─6641 sshd: nebulosa@pts/0
                      │ ├─6642 -bash
                      │ ├─8203 loginctl user-status
                      │ └─8204 less
                      └─user@1000.service
                        └─init.scope
                          ├─874 /usr/lib/systemd/systemd --user
                          └─878 (sd-pam)
    
    Nov 22 21:52:08 vpshost systemd[874]: Listening on GnuPG cryptographic agent and passphrase cache (access for web browse>
    Nov 22 21:52:08 vpshost systemd[874]: Listening on GnuPG cryptographic agent and passphrase cache (restricted).
    Nov 22 21:52:08 vpshost systemd[874]: Listening on GnuPG cryptographic agent (ssh-agent emulation).
    Nov 22 21:52:08 vpshost systemd[874]: Listening on GnuPG cryptographic agent and passphrase cache.
    Nov 22 21:52:08 vpshost systemd[874]: Listening on p11-kit server.
    Nov 22 21:52:08 vpshost systemd[874]: Listening on D-Bus User Message Bus Socket.
    Nov 22 21:52:08 vpshost systemd[874]: Reached target Sockets.
    Nov 22 21:52:08 vpshost systemd[874]: Reached target Basic System.
    Nov 22 21:52:08 vpshost systemd[874]: Reached target Main User Target.
    Nov 22 21:52:08 vpshost systemd[874]: Startup finished in 87ms.
    
    52th
    Лично меня смущают эти две подряд идущие записи:
    Nov 20 09:32:44 vpshost systemd-networkd[296]: ens3: Interface name change detected, ens3 has been renamed to eth0.
    Nov 20 09:32:44 vpshost systemd-networkd[296]: eth0: Interface name change detected, eth0 has been renamed to ens3.
    То есть сначала ens3 переименовывают в eth0, а затем обратно.
    Может копнуть в эту сторону: переименовать интерфейс вручную?

    Также не помогло, потом вернул обратно. Оба варианта пробовал.

    
    $ journalctl -n 30  -u systemd-networkd
    -- Logs begin at Thu 2019-11-21 01:09:36 MSK, end at Fri 2019-11-22 21:40:39 MSK. --
    Nov 22 21:24:11 vpshost systemd-networkd[317]: ens3: IPv6 successfully enabled
    Nov 22 21:24:11 vpshost systemd-networkd[317]: ens3: Gained carrier
    Nov 22 21:24:12 vpshost systemd-networkd[317]: ens3: Gained IPv6LL
    Nov 22 21:24:23 vpshost systemd-networkd[317]: wg0: Gained carrier
    Nov 22 21:24:23 vpshost systemd-networkd[317]: wg0: Lost carrier
    Nov 22 21:34:58 vpshost systemd[1]: Stopping Network Service...
    Nov 22 21:34:58 vpshost systemd[1]: systemd-networkd.service: Succeeded.
    Nov 22 21:34:58 vpshost systemd[1]: Stopped Network Service.
    -- Reboot --
    Nov 22 21:35:14 vpshost systemd[1]: Starting Network Service...
    Nov 22 21:35:15 vpshost systemd-networkd[302]: Enumeration completed
    Nov 22 21:35:15 vpshost systemd[1]: Started Network Service.
    Nov 22 21:35:15 vpshost systemd-networkd[302]: ens3: Interface name change detected, ens3 has been renamed to eth0.
    Nov 22 21:35:15 vpshost systemd-networkd[302]: eth0: Interface name change detected, eth0 has been renamed to ens3.
    Nov 22 21:37:16 vpshost systemd-networkd[302]: wg0: Gained carrier
    Nov 22 21:40:07 vpshost systemd-networkd[302]: wg0: Lost carrier
    Nov 22 21:40:07 vpshost systemd-networkd[302]: Could not emit changed properties: Transport endpoint is not connected
    Nov 22 21:40:07 vpshost systemd-networkd[302]: Could not emit changed properties: Transport endpoint is not connected
    Nov 22 21:40:07 vpshost systemd[1]: Stopping Network Service...
    Nov 22 21:40:07 vpshost systemd[1]: systemd-networkd.service: Succeeded.
    Nov 22 21:40:07 vpshost systemd[1]: Stopped Network Service.
    -- Reboot --
    Nov 22 21:40:22 vpshost systemd[1]: Starting Network Service...
    Nov 22 21:40:23 vpshost systemd-networkd[302]: Enumeration completed
    Nov 22 21:40:23 vpshost systemd[1]: Started Network Service.
    Nov 22 21:40:23 vpshost systemd-networkd[302]: ens3: Interface name change detected, ens3 has been renamed to eth0.
    Nov 22 21:40:23 vpshost systemd-networkd[302]: eth0: Interface name change detected, eth0 has been renamed to ens3.
    Nov 22 21:40:23 vpshost systemd-networkd[302]: ens3: IPv6 successfully enabled
    Nov 22 21:40:23 vpshost systemd-networkd[302]: ens3: Gained carrier
    Nov 22 21:40:25 vpshost systemd-networkd[302]: ens3: Gained IPv6LL
    Nov 22 21:40:37 vpshost systemd-networkd[302]: wg0: Gained carrier
    

    Заметил ещё одну вещь, теперь достаточно только подключиться через VNC и уже без ввода логина поднимается сеть. Возможно и до этого работало - я не ждал вводил логин сразу, а тут отвлёкся и увидел такое поведение.
    В логах пусто:
    
    $ journalctl -n 30  -u systemd-networkd
    -- Logs begin at Wed 2019-11-20 01:31:42 MSK, end at Wed 2019-11-20 21:42:44 MSK. --
    Nov 20 09:24:04 vpshost systemd-networkd[304]: ens3: Gained carrier
    Nov 20 09:24:06 vpshost systemd-networkd[304]: ens3: Gained IPv6LL
    Nov 20 09:24:17 vpshost systemd-networkd[304]: wg0: Gained carrier
    Nov 20 09:24:18 vpshost systemd-networkd[304]: wg0: Lost carrier
    Nov 20 09:32:27 vpshost systemd[1]: Stopping Network Service...
    Nov 20 09:32:27 vpshost systemd[1]: systemd-networkd.service: Succeeded.
    Nov 20 09:32:27 vpshost systemd[1]: Stopped Network Service.
    -- Reboot --
    Nov 20 09:32:43 vpshost systemd[1]: Starting Network Service...
    Nov 20 09:32:44 vpshost systemd-networkd[296]: Enumeration completed
    Nov 20 09:32:44 vpshost systemd[1]: Started Network Service.
    Nov 20 09:32:44 vpshost systemd-networkd[296]: ens3: Interface name change detected, ens3 has been renamed to eth0.
    Nov 20 09:32:44 vpshost systemd-networkd[296]: eth0: Interface name change detected, eth0 has been renamed to ens3.
    Nov 20 09:32:44 vpshost systemd-networkd[296]: ens3: IPv6 successfully enabled
    Nov 20 09:32:44 vpshost systemd-networkd[296]: ens3: Gained carrier
    Nov 20 09:32:46 vpshost systemd-networkd[296]: ens3: Gained IPv6LL
    Nov 20 09:32:57 vpshost systemd-networkd[296]: wg0: Gained carrier
    Nov 20 09:33:35 vpshost systemd-networkd[296]: wg0: Lost carrier
    Nov 20 09:33:35 vpshost systemd[1]: Stopping Network Service...
    Nov 20 09:33:35 vpshost systemd[1]: systemd-networkd.service: Succeeded.
    Nov 20 09:33:35 vpshost systemd[1]: Stopped Network Service.
    -- Reboot --
    Nov 20 09:33:52 vpshost systemd[1]: Starting Network Service...
    Nov 20 09:33:53 vpshost systemd-networkd[299]: Enumeration completed
    Nov 20 09:33:53 vpshost systemd[1]: Started Network Service.
    Nov 20 09:33:53 vpshost systemd-networkd[299]: ens3: Interface name change detected, ens3 has been renamed to eth0.
    Nov 20 09:33:53 vpshost systemd-networkd[299]: eth0: Interface name change detected, eth0 has been renamed to ens3.
    Nov 20 09:33:53 vpshost systemd-networkd[299]: ens3: IPv6 successfully enabled
    Nov 20 09:33:53 vpshost systemd-networkd[299]: ens3: Gained carrier
    Nov 20 09:33:55 vpshost systemd-networkd[299]: ens3: Gained IPv6LL
    Nov 20 09:34:07 vpshost systemd-networkd[299]: wg0: Gained carrier
    Nov 20 09:34:06 vpshost systemd-networkd[299]: wg0: Lost carrier
    

    при этом логин через SSH каждый раз проходил по схеме описанной выше:
    пример:
    ➤ 	 [Abnormal Disconnect 20 Nov 2019, 09:23:46]
    ➤ 	 [Abnormal Disconnect 20 Nov 2019, 09:23:49]
    ➤ 	 [Abnormal Disconnect 20 Nov 2019, 09:24:01]
    ➤ 	 [Abnormal Disconnect 20 Nov 2019, 09:24:04]
    ➤ 	 [Abnormal Disconnect 20 Nov 2019, 09:24:07]
    ➤ 	 [Abnormal Disconnect 20 Nov 2019, 09:24:10]
    ➤ 	 [Abnormal Disconnect 20 Nov 2019, 09:24:13]
    ➤ 	 [Abnormal Disconnect 20 Nov 2019, 09:24:17]
    ➤ 	 [Connected 20 Nov 2019, 09:24:21]
    Файлы настройки сети стандартные:

    cat /etc/systemd/network/default.network
    [Match]
    Name=ens3
    
    [Network]
    Gateway=<ip_gateway>
    Address=<ip>/24
    DNS=1.1.1.1
    Немного поковырялся, получается что сеть настроена через сокет и каким-то образом (видимо при логине на tty ) сеть поднимается. Значит надо как-то переключить чтобы сеть поднималась сама, автоматически. Попробовал тупо удалить файл сокета и активировать сервис, но без файла сокета ничего не активируется..

    $ systemctl list-unit-files | grep systemd-network
    systemd-network-generator.service          disabled
    systemd-networkd-wait-online.service       enabled
    systemd-networkd.service                   enabled
    systemd-networkd.socket                    enabled 

    Какие мысли, в правильном направлении думаю?