dikoobraz, я не вижу текущего состояния вашей системы.
Пожалуйста, покажите, что выводят команды
pacman -Qs virtualbox
lsmod|grep vbox
ip addr
ip route
ДО выполнения каких-либо ваших команд.
Был такой старинный анекдот о паровозе – "Всё понял, только никак не пойму, куда лошадь запрягать".

На хосте адрес 192.168.100.1 с маской 255.255.255.0 должен быть прописан в настройках VirtualBox для vboxnet0.
Никаких команд в консоли на хосте выполнять не нужно.
dikoobraz, на гостевой системе НЕ НАДО БЫЛО ничего менять :)
Зачем вы пытаетесь прописать на двух узлах сети ОДИН АДРЕС? Вот потому и ОПЯТЬ не работает.

Чтобы хост A мог общаться по сети с хостом B, их адреса, в общем случае, должны быть, как минимум, РАЗНЫМИ.

В вашем случае, на хосте должно быть 192.168.100.1 (указано в настройках VirtualBox, никаких команд не нужно!), а на госте 192.168.100.100 (указано в файле interfaces Убунты).

Подключаясь к вашему "серверу", вы с адреса 192.168.100.1 (хост) обращаетесь к ДРУГОМУ адресу 192.168.100.100 (виртуалка).
В противном случае, если вы с обеих концов задатите хоть 192.168.100.1, хоть 192.168.100.100, ваш хост будет обращаться САМ К СЕБЕ, и разумеется, ничего не заработает.
Теперь всё очевидно.
У вашей гостевой системы адрес 192.168.100.100, а у хоста сразу два адреса: 192.168.100.1 и 192.168.100.100.
Первый присваивает VirtualBox согласно своих настроек, а второй вы присваиваете зачем-то сами.
Поскольку адрес совпадает, вместо гостевой системы вы коннектитесь к хосту, на котором нет веб и FTP, а SSH есть, но с другими учётными данными.

Насколько я понимаю, вам не нужно ничего руками делать с интерфейсом vboxnet0, его поднимает сама VirtualBox, когда запускает виртуалку с гостевой системой. Тем более не стоит назначать ему адрес гостевой системы, тем самым блокируя себе к ней доступ.

Загружать модули вручную командой modprobe тоже, насколько я понимаю, не требуется.
Если вы ставили эти модули пакетом virtualbox-host-dkms, то у вас уже есть файлик /usr/lib/modules-load.d/virtualbox-host-dkms.conf, загружающий их автоматически при старте системы.
Непонятно, зачем такие сложности, почему нельзя установить все те же самые L, A, M и P на хост-машине, но тут уж дело хозяйское, каждый упражняется как хочет.

RusWolf, за DHCP на eth1 отвечает сам VirtualBox, когда предоставляет виртуальную сеть типа "NAT", через которую гостевая система попадает в интернет.
К интерфейсу vboxnet0eth0 в виртуалке) это не имеет отношения.

dikoobraz
sudo ip link set dev vboxnet0 up
sudo ip addr add 192.168.100.100/24 dev vboxnet0
sudo ip route add 192.168.100.0/24 dev vboxnet0
Последняя команда ip route бессмысленна, роут на подсеть автоматически создается предыдущей командой ip addr.
Насколько я понимаю, она должна выдавать ошибку вида "RTNETLINK answers: File exists".
Вы хотя бы следите за ответами этих команд, когда их выполняете?

В VitrualBox на текущий момент я не обнаружил проблем, которые могли бы вам мешать. Я специально проверил у себя виртуалку с тремя виртуальными интерфейсами, из них два vboxnet, всё работает как положено.

Чтобы разобраться в происходящем у вас, желательно знать не просто ваши настройки (в вашем представлении), а их результат.

Пожалуйста, покажите вывод команд
ip addr
ip route
iptables-save
на хост-машине и на гостевой. На всякий случай: iptables-save нужно выполнять из-под рута.

Кроме того, неплохо было бы выяснить, действительно ли работают ваши веб, ssh и ftp сервисы на гостевой машине.
Ох, дожили. Столько советчиков, а ман покурить некому.
Non-superuser mounts
Normally, only the superuser can mount filesystems. However, when fstab contains the user option on a line, anybody can mount the corresponding filesystem.
Thus, given a line
              /dev/cdrom  /cd  iso9660  ro,user,noauto,unhide
any user can mount the iso9660 filesystem found on an inserted CDROM using the command:
              mount /cd
Note that mount is very strict about non-root users and all paths specified on command line are verified before fstab is parsed or a helper program is executed. It's strogly recommended to use a valid mountpoint to specify filesystem, otherwise mount may fail. For example it's bad idea to use NFS or CIFS source on command line.
For more details, see fstab(5). Only the user that mounted a filesystem can unmount it again. If any user should be able to unmount it, then use users instead of user in the fstab line. The owner option is similar to the user option, with the restriction that the user must be the owner of the special file. This may be useful e.g. for /dev/fd if a login script makes the console user owner of this device. The group option is similar, with the restriction that the user must be member of the group of the special file.
Итак, есть ЧЕТЫРЕ разные опции user, users, owner и group с похожим, но разным действием. Только опция group требует принадлежности пользователя к группе устройства (например, storage), но user и users – никаких групп для монтирования от пользователя не требуют.

Команда mount от юзера у Morteryler должна работать. Судя по сообщениям об ошибке, у него установлен какой-то скрипт или алиас, подменяющий эту команду, и добавляющий неразрешенный юзеру --options, для проверки можно попробовать писать /bin/mount вместо mount, если не получится – смотреть, что покажет
ls -l /bin/mount*
Volldemar
у меня этот пакет собрался без проблем
vtun? Почему нет, если я его уже давно исправил :)

vasek
--with-ssl-headers как я понял обязательно - без этой опции автоматом заголовок от openssl-1.0 не пропишется?
Думаю, как раз это одна из опций, специфичных для сборки vtun.

Попробуйте открыть страницу пакета openssl-1.0 и пройтись по списку зависимых от него пакетов. Для каждого в Source files можно посмотреть, как в каждом конкретном случае решали проблему.

По-моему, самый популярный способ – добавление переменных
PKG_CONFIG_PATH=/usr/lib/openssl-1.0/pkgconfig  CFLAGS+=" -I/usr/include/openssl-1.0"  LDFLAGS+=" -I/usr/lib/openssl-1.0"
перед ./configure
Volldemar
Кто сталкивался с этой проблемой и победил?
Я сталкивался и победил, но для одного конкретного пакета.
Другие пакеты могут собираться по-другому.
"Полечить проблему" может оказаться не очень просто.
Суть в том, что в Арч перешли на новую ветку openssl 1.1, а старую переименовали в openssl-1.0.

В результате в пакетах, которые требуют openssl старой ветки 1.0, нужно не просто заменить зависимость openssl на openssl-1.0, а заставить собираться с заголовочными файлами старой ветки, которые перемещены из /usr/include/openssl/ в /usr/include/openssl-1.0/openssl/
После последних обновлений LibreOffice (любой ветки, still и fresh) стал отказываться открывать (некоторые?) файлы .docx с безумными сообщениями вида:
Ошибка формата файла в позиции
SAXParseException: '[word/document.xml line 2]: Input is not proper UTF-8, indicate encoding !
Bytes: 0xD0 EOF
', Stream 'word/document.xml', Line 2, Column 53386(строка, столбец).
Грубо говоря, он стал неожиданно находить конец строки в её середине.
Виновник – libxml2-2.9.4+96+gfb56f80e-1-x86_64
Откат на libxml2-2.9.4+16+g07418011-2-x86_64 решает проблему.