Если понял верно,похоже,что с настройкой сети и маршрутизации где-то перемудрили. Отключите вначале файерволл на основной ОС , попробуйте запустить одну виртуалку в режиме Nat , сможет ли она вообще выйти в интернет. Потом , если настраивается внутрення сеть,то у вм должны быть включены 2 адаптера , чтобы 1 был как мост (в качестве моста обычно указывается карта роутера), а 2-ой как внутренняя сеть был подключен, ну и гостевых ос разрешение подключеий. Пока попробуйте исключить файерволл.Далее надо проверять настройки маршрутизатора и вм .Если проблема не решится , то переходить к проверке настроек интерфейса гостевых ос , добавлены ли в них и активированы по второму интерфейсу и файлов /etc/resolv.conf и /etc/network/interfaces , в необходимости чего сомневаюсь, если ранее всё работало и не было изменений.
РАЗБОР
firewall или сеть?
[ обложка статьи ]
Режим чтения
Не могу разобраться в чем дело. стоит виртуальная сеть на virtualbox. с ней с неделю назад вообще проблемы начались во всех виртуалках, но там чисто тормоза появились. неприятно но не смертельно(виртуалбокс сносил и заново ставил, результат тот же)
Но с виртуалкой на Кали вообще внутренней сети нету.
раньше стояли 2 сетевых адаптера , один на НАТ , второй внутренняя сеть. и все работало , но потом перестало. убрал сначала первый адаптер с НАТ (ну мало ли роуты или еще чего , хотя не должно). итог тот же самый.
сейчас апач запущен , с кали на себя заходит и по http://127.0.0.1 и http://192.168.1.10 (это я к тому что апач смотри все айпи адреса), с других виртуалок Кали и не пингуется , и на ее веб не заходит, на ssh тоже не заходит.
думал файер блокирует , но
root@kali:~# service iptables status
Unit iptables.service could not be found.
ну понятно , iptables тут типа и не стояло , читал что есть еще ufw , и гуи к нему gufw . там файер отключен , в консоли проверяю
root@kali:~# service ufw status
ufw.service - Uncomplicated firewall
Loaded: loaded (/lib/systemd/system/ufw.service; disabled; vendor preset: disabled)
Active: inactive (dead)
и я уже не знаю на кого думать , то ли файер все блокирует , то ли сеть у виртуалбокса глючит . но в виндовых виртуалках все пашет (правда сеть тормозит , пинг до 600мс и это блин на хоть и виртуальной но все же локальной сети) .
[doublepost=1489607973,1489601596][/doublepost]а сейчас блин вообще при пинге выдает
Destination Host Unreachable
и это при том что обе виртуалки находятся в одной сети
192.168.1.*
и у обеих сетевуха в режиме "внутренняя сеть"
Но с виртуалкой на Кали вообще внутренней сети нету.
раньше стояли 2 сетевых адаптера , один на НАТ , второй внутренняя сеть. и все работало , но потом перестало. убрал сначала первый адаптер с НАТ (ну мало ли роуты или еще чего , хотя не должно). итог тот же самый.
сейчас апач запущен , с кали на себя заходит и по http://127.0.0.1 и http://192.168.1.10 (это я к тому что апач смотри все айпи адреса), с других виртуалок Кали и не пингуется , и на ее веб не заходит, на ssh тоже не заходит.
думал файер блокирует , но
root@kali:~# service iptables status
Unit iptables.service could not be found.
ну понятно , iptables тут типа и не стояло , читал что есть еще ufw , и гуи к нему gufw . там файер отключен , в консоли проверяю
root@kali:~# service ufw status
ufw.service - Uncomplicated firewall
Loaded: loaded (/lib/systemd/system/ufw.service; disabled; vendor preset: disabled)
Active: inactive (dead)
и я уже не знаю на кого думать , то ли файер все блокирует , то ли сеть у виртуалбокса глючит . но в виндовых виртуалках все пашет (правда сеть тормозит , пинг до 600мс и это блин на хоть и виртуальной но все же локальной сети) .
[doublepost=1489607973,1489601596][/doublepost]а сейчас блин вообще при пинге выдает
Destination Host Unreachable
и это при том что обе виртуалки находятся в одной сети
192.168.1.*
и у обеих сетевуха в режиме "внутренняя сеть"
Содержание
Codeby Academy
Практика и мастерство
От основ до продвинутого — программы для практиков Codeby.
Перейти к курсу →
это по ходу глюк виртуалбокса , удалил виртуалку с кали и все стало работать . при чем это не глюк виртуальной ОС , это глюк именно виртуалбокса.
а по теме - везде файеры были отключены .
ситуация такая - стоит виртуальный домен
сервер вин2008 192.168.1.1 он же и шлюз
рабочие станции вин7 192.168.1.11, 192.168.1.12
кали 192.168.1.13
каликде 192.168.1.14
у всех кроме сервер сетевая карта в режиме "внутренняя сеть" , у сервера есть еще и НАТ .
добавление карты с НАТом добавляет еще один выход в инет , в том числе и на обеих кали , но на кали вр внутренней сети это не влияло никак .
кали (обе) никого не видели , и их никто не видел . хотя фаер потушен и сеть настроена нормально.
после удаление каликде , сеть работать начала .
но сеть все равно тупит . пинг в локалке 600мс .
а по теме - везде файеры были отключены .
ситуация такая - стоит виртуальный домен
сервер вин2008 192.168.1.1 он же и шлюз
рабочие станции вин7 192.168.1.11, 192.168.1.12
кали 192.168.1.13
каликде 192.168.1.14
у всех кроме сервер сетевая карта в режиме "внутренняя сеть" , у сервера есть еще и НАТ .
добавление карты с НАТом добавляет еще один выход в инет , в том числе и на обеих кали , но на кали вр внутренней сети это не влияло никак .
кали (обе) никого не видели , и их никто не видел . хотя фаер потушен и сеть настроена нормально.
после удаление каликде , сеть работать начала .
но сеть все равно тупит . пинг в локалке 600мс .
Верно , тайм-аут нездоровый . Вот ключ к проблеме - "Destination Host Unreachable" и в самом значении пинга. Здесь лучше бы вооружиться traceroute или mtr . Но вначале посмотреть , на той же Kali ,что route выдаёт . В VB фигурируют адреса вида 10.0.х.х. и по умолчанию используются они системой в качестве предпочитаемого шлюза .Метрику смотрите при выводе route , если задействованы оба шлюза 10.0.х.х и 192.168.х.х , и у всех флаги UG , где она короче - тому и приоритет , либо шлюзом дует один 10.0.х.х вопреки ожидаемому 192.168.х.х . traceroute Вам подскажет с каким узлом проблема и где этот самый высокий пинг.Если всё окажется так , то делайте принудительное переназначение метрик , т.е. приоритета по умолчанию , в конфигурационном файле /etc/NetworkManager/NetworkManager.conf тогда тоже надо будет прописывать и метрику , static адреса , а в строке managed=true указать fulse , т.е. что управляться будет вручную.
а какой может быть traceroute в локальной сети ?
route на кали когда была одна сетевуха (сейчас то уже не проверишь все варианты . ту виртуалку удалил) был нормальный , дефолтный шлюз 192.168.1.1
проблемы не было даже когда ДНС сменил на калевский (dnschef, dns2proxy), все пахало как часики . а после создания новой виртуалки на каликде пошли косяки , при чем не сразу . и даже после удаления ее косяки в виде тормозов все равно остались .
route на кали когда была одна сетевуха (сейчас то уже не проверишь все варианты . ту виртуалку удалил) был нормальный , дефолтный шлюз 192.168.1.1
проблемы не было даже когда ДНС сменил на калевский (dnschef, dns2proxy), все пахало как часики . а после создания новой виртуалки на каликде пошли косяки , при чем не сразу . и даже после удаления ее косяки в виде тормозов все равно остались .
Так это же утилита из диагностиков, ей и не обязательно проверять какие-то удалённые домены с выходом наружу.При построении маршрута и отладке в локальной сети одна из лучших помощников. И в изолированной сетке до любого узла достучаться может,хоть до принтера,хоть до шлюзового узла , для этого и ключи имеются ,например -A . Ладно,спорить не буду, причин может быть много для сбоев в сети.
Продолжить чтение
Следующий разбор
RedAmon: open source инструменты для пентеста 2026
Ещё по теме
4
СтатьяUX Astra Linux или при чем тут UX и безопасность?
8
4 тыс.
15.08.2026
СтатьяПентест АСУ ТП: kill chain от корпоративной сети до регистров контроллера
0
797
11.06.2026
СтатьяУстановка Parrot OS: пошаговый гайд для пентестера - от загрузки ISO до первого сканирования
2
2 тыс.
21.08.2026
СтатьяПроверка рабочей станции перед Red Team операцией: чек-лист оператора
0
3 тыс.
25.08.2026
Комментарии
5