Дядька Серёжа, может не стоит диагностировать предысторию по гарнитуре шрифта? Я ничего не имею против нормальных специалистов, которые в своих приоритетах имеют, помимо прямых задач по обеспечению безопасности, также и не создание неоправданных проблем и неудобств коллегам и пользователям, но к сожалению, мой личный опыт взаимодействия с такими людьми весьма неоднозначен. Будучи админом очень большой и развесистой сети в госструктуре, где отдел сетевого администрирования и отдел безопасности были в разных структурных подразделениях, насмотрелся всякого. "Юные дарования", которых брали специалистами в сектор сетевой безопасности, дорвавшись до инструментов сканирования уязвимостей, несколько раз вызывали массовые проблемы, в частности, блокировку доменных учеток по причине исчерпания лимита подбора паролей или массовое зависание ip-телефонов. Они же только хлопали глазами, когда в сети начинались какие-то реальные проблемы, например вследствие arp-спуфинга, несмотря на то, что весь трафик зеркалировался на их многочисленные сенсоры, начиная от Snort и кончая чем-то сертифицированным. Продукция компании Инфотекс, которую они ставили везде, где только можно, потому что так положено, и потом обслуживали, регулярно вызывала сбои в работе защищаемых сетей и часто, как следствие, информационных систем, в разы чаще, чем использованное не сертифицированное оборудование традиционных вендоров, и при этом безопасники обычно еще и до последнего отказывались признавать проблему на своей стороне. И это при том, что они административными регламентами вытребовали себе доступ на все сетевое оборудование, при этом оставив контроль за всем, что относится к безопасности, лишь за собой. Когда же на ключевом сетевом оборудовании западного производителя случился сбой, потребовавший обращения в его техподдержку, они фактически заблокировали решение проблемы, запретив выдавать каким-либо зарубежным организациям значимую информацию - конфиги, логи и дампы. А российский партнер, у которого все закупалось, только развел руками и ничем помочь не смог. Конечно, не все было совсем уж только плохо, но в конечном итоге воинствующая паранойя, исходившая от безопасников, стала для меня одним из факторов, побудивших искать новое место работы, где к вопросам безопасности относятся более сбалансировано. А про кодекс корпоративной этики в госструктуре... Я лучше промолчу.
Понятно. Покажите конфиг секции /ppp, может будет понятно, почему windows не может подключиться. Маршрутизацию специальным образом настраивать не нужно, достаточно, чтобы для pppoe-клиентов в ppp -> secrets были прописаны адреса local и remote, а также были правильные настройки в service и profile .
Для портов T1/E1 исправность можно проверить с помощью loopback-адаптера (или как его еще называют, "заворота"). Для ISDN, насколько я знаю, это тоже должно работать, только адаптер требуется с другой распиновкой. В простейшем случае это джек RJ-45, обжатый по схеме
Собственно, можно купить готовое устройство, например https://www.computercablestore.com/isdn-bri-loopba...
Само по себе оно ничего не тестирует, но при включении его в тестируемое устройство порт должен подняться, если с ним все в порядке.
dieselb01, расскажите предысторию подробнее, если возможно. В крупных провайдерах типа Ростелекома такое индивидуальное отношение к клиенту, что ему стали избирательно шейпить трафик, вряд ли возможно, но в небольших - вероятность отлична от нуля. Но чтобы такой сценарий реализовался, требуется что-то из ряда вон выходящее.
Emiroff, под вашу задачу я бы взял https://dlink.ru/ru/products/1/2001.html (тем более, что такие коммутаторы мной уже использовались, и опыт положительный). У этого коммутатора явно обозначено, что SFP-порты могут работать на скорости 100 Мбит (в отличие от того, который вы ранее выбрали). SFP-модули скорее всего подойдут, коммутаторы D-Link как правило совместимы с любыми нормальными модулями (в отличие от Cisco или HP, которые нужны "родные" трансиверы).
Emiroff, думаю, вам нужны SFP-модули типа таких (а чтобы выяснить наверняка, нужно узнать, какие частоты используют медиаконвертеры, с хорошей вероятностью на них это должно быть написано, даже если они noname): https://dlink.ru/ru/products/1/1590.html https://dlink.ru/ru/products/1/1591.html
И свич тоже должен поддерживать скорость 100 Мбит/с на SFP-портах. Для гигабитных свичей это выполняется не всегда.
Emiroff, и работает по одному волокну? Обычно в таком случае используются разные длины волн, и соответственно на разных концах кабеля используются симметричные устройства, у которых частоты на прием и на передачу "крест на крест".
С точки зрения браузера, если он попадает на сайт, сертификат которого не соответствует запрашиваемому, то это подмена сертификата и нужно как минимум вывести предупреждение. Тут нет универсального способа обойти эту проблему.
В общем, чтобы превратить proxmox в рабочую станцию с графическим окружением, с которой в том числе можно будет администрировать её саму, в минимальном варианте достаточно команды apt install xserver-xorg firefox-esr xfce4
На моем тестовом сервере на Proxmox Virtual Environment 6.3-3 ̶и̶з̶н̶а̶с̶и̶л̶о̶в̶а̶н̶и̶е̶ тестирование прошло вполне успешно, после этой команды и ребута сервер перешел в графический режим и оконная среда нормально заработала.
Используйте утилиты командной строки (pve* и т.д.) для управления сервером. Это при желании тоже возможно. А стандартная веб-консоль proxmox без браузера, что вполне очевидно, не работает. Чем вам наличие браузера не нравится?
Сергей Булатов, пара грамотных монтажников проложат кабель один раз и навсегда, избавив от подобных проблем. А с WiFi вы так и будете зависеть от неподконтрольных вам факторов. К тому это работает в обе стороны и ваши 100 Мбит/с могут основательно мешать работе WiFi у соседей, если они рядом.
Насколько я помню, на ESXi 6.0 проброс физических устройств в виртуалку сразу выключал возможность использования живой миграции, HA и снапшотов. Что в общем-то вполне логично.
