Ssh, соединяющийся со Статическим IP
Я не эксперт Cisco, но обычно конфигурация достаточно гибка так, чтобы Вы могли заблокировать общие порты HTTP (80, 443, 808x, и т.д.) MAC-адресом или IP-адресом, если Вам нравится. Это не действительно гибкий метод все же.
То, что я сделал бы:
- Настройте прокси-сервер где-нибудь (Сквид, Nginx, Сервер ISA, и т.д.).
- Включите аутентификацию прокси и настройте некоторый ACLs на основе аутентификации пользователя и/или IP-адреса. Протестируйте это, чтобы удостовериться, что это ведет себя как ожидалось, в зависимости от используемого имени пользователя.
- После того, как удовлетворенный, примените GPO, который указывает на Ваши клиентские компьютеры на прокси. Тест, что, чтобы быть уверенным это действительно блокирует пользователей.
- На маршрутизаторе, блок исходящие связанные с HTTP порты из Вашей сети, кроме от прокси-сервера.
Теперь Вы имеете мелкомодульный контроль на том, кому разрешают доступ к HTTP, и Вы не должны играть с конфигурацией маршрутизатора каждый раз, когда Вы добавляете пользователей, компьютеры, и т.д. Я предлагаю также, чтобы Вы всегда предоставили доступ к сайтам, которые обеспечивают автоматические обновления (как Windows Updates, обновления от Вашего поставщика AV, и т.д.).
Устройство маршрутизации с общедоступным IP-адресом должно перенаправлять трафик порта 22 на сервер Ubuntu, который находится за брандмауэром. Если вы сообщите нам, что это за межсетевой экран / граничное устройство, мы сможем указать вам более конкретное направление.
РЕДАКТИРОВАТЬ: Вам нужно будет проверить, действительно ли трафик отправляется на ваш Сервер Ubuntu. Запустите tcpdump , чтобы проверить, не попадает ли SSH-трафик на ваш сервер. Если это не так, проблема с граничным маршрутизатором все еще существует. Если это так, то вы можете сосредоточиться на сервере Ubuntu. Как только вы это поймете, мы сможем помочь вам больше.
РЕДАКТИРОВАТЬ 2: Если вы настроили переадресацию портов для порта 22, маршрутизатор обрабатывает трансляцию для всего трафика, привязанного к порту 22, направленного на публику. IP-адрес и немедленно отправляет трафик на сервер Ubuntu. Затем сервер Ubuntu видит трафик, исходящий от маршрутизатора, и любые ответы на трафик порта 22 отправляются на маршрутизатор, который затем пересылает его вам. Маршрутизатор обрабатывает всю трансляцию трафика, поддерживая таблицу с указанием того, кто к какому порту обращается, и назначая уникальные сеансы каждому коммуниканту. Таким образом, даже несколько человек могут разговаривать с сервером Ubuntu через ssh, используя внешний IP-адрес.
Например: если у вас дома есть внешний IP-адрес 1.1.1.1, а у офисного маршрутизатора внешний IP-адрес 2.2. 2.2, а сервер Ubuntu имеет локальный IP-адрес 192.168.1.10 (за маршрутизатором 2.2.2.2), потоки трафика выглядят следующим образом:
- 1.1.1.1 подключается к 2.2.2.2:22 [128 visible2.2.2.2:22 получает переадресовано на 192.168.1.10:22.
- 192.168.1.10:22 отвечает маршрутизатору на 2.2.2.2:22 (ну, в действительности он отвечает на локальный IP-адрес маршрутизатора, а не на общедоступный IP-адрес. В этом примере это, вероятно, будет 192.168.1.1:22.)
- Затем маршрутизатор перенаправляет информацию обратно на общедоступный IP-адрес вашего дома 1.1.1.1.
tdpdump may be an overkill here. Just do telnet from outside and telnet localhost 22 on your ubuntu server. Ssh server should respond immediately with something like 'SSH-2.0-OpenSSH_5.8p1-hpn13v10'.
If telnet from localhost does not work, you have problems with your ssh server. If telnet from localhost works, but not from outside, this is probably router-related problem. If both works, this might be your ssh client problem.
And another one guess: check your firewall rules on the server. You can print out them by running /sbin/iptables -L.
Please update your answer with results of telnet diagnostics and with list of your firewall rules, so we'll be able to give you better advice.