Проброс портов на сервер

Приключилась тут со мной интересная ситуация.
Дано:

• Домашняя сеть 172.0.0.0/24;
• Домашний сервер 172.0.0.2, у которого прописан в качестве шлюза по умолчанию адрес маршрутизатора 172.0.0.1 (о нем ниже). К этому серверу осуществляется доступ по ssh;
• Маршрутизатор mikrotik, через который осуществляется доступ в Интернет. Внутренний адрес маршрутизатора - 172.0.0.1, внешний (WAN) - 77.88.8.8; На маршрутизаторе настроена трансляция сетевых адресов (NAT) типа Masquerading - адреса внутренней сети транслируются во внешний;
• Зарегистрированное доменное имя homeserver.com, привязанное к 77.88.8.8;
• Ноутбук, с которого осуществляется подключение к домашнему серверу по доменному имени homeserver.com;

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

Для решения задачи доступа из Интернета, я использовал Destination NAT, более известный как "проброс портов". На маршрутизаторе настраивается правило для таблицы NAT в цепочке dst-nat, суть которого можно описать так: если от WAN интерфейса извне пришел пакет на ssh порт 22, то перенаправить этот пакет на домашний сервер на тот же 22ой порт. За счет этого появляется возможность подключаться из Интернета к homeserver.com.

Осталось только решить вопрос доступа из локальной сети. Допустим ноутбук, находясь в локальной сети, будет иметь адрес 172.0.0.3. Это та же самая сеть, в которой находится домашний сервер. К серверу в таком случае без проблем можно обратиться по адресу 172.0.0.2. Но мы хотим обращаться к нему по адресу homeserver.com, а это имя, как мы помним, привязано к адресу 77.88.8.8. Если мы введем команду ssh homeserver.com на ноутбуке, желая подключиться по ssh к серверу, то ответит нам не сервер, а маршрутизатор, т.к. 77.88.8.8 это именно его адрес на порту WAN. Надо как-то сообщить маршрутизатору, чтобы пакеты на 22ой порт, идущие из локальной сети, тоже отправлялись на адрес сервера. Сделать это очень просто: нужно добавить еще одна правило в цепочку dst-nat таблицы NAT, которое в случае поступления пакетов на 22ой порт из интерфейсов LAN сети, будет перенаправлять эти пакеты на сервер. Это правило будет аналогично правилу для WAN, но отличается от него тем, что теперь обрабатываются пакеты, пришедшие из локальной сети. В качестве альтернативы можно не создавать новое правило, а изменить предыдущее, убрав оттуда условие, проверяющее интерфейс, с которого поступил пакет. Тогда все пакеты, пришедшие на маршрутизатор на 22 порт, будут отправлены на сервер.

А теперь интересность: получив такой сетап, подключение к серверу из локальной сети 172.0.0.0/24 работать всё равно не будет. И что еще более интересно, работать подключение начнет, если добавить еще одну локальную сеть, не пересекающуюся с 172.0.0.0/24. Например, добавив на маршрутизатор адрес 10.1.1.1 и переведя ноутбук в сеть 10.1.1.0/24, подключения к серверу будут работать. Как же так получается?

Для этого представим путь, который проходит пакет, запрашивающий соединение по ssh, и идущий из локальной сети 172.0.0.0/24. Ноутбук, имея адрес 172.0.0.3, отправит запрос на подключение к homeserver.com. Перед непосредственно отправкой пакета на запрос соединения произойдет преобразование доменного имени в адрес 77.88.8.8. Именно туда и будет отправлен пакет на 22ой порт. Т.к. адрес 77.88.8.8 находится не в сети 172.0.0.0/24, то ноутбук отправит пакет на шлюз по умолчанию на адрес 172.0.0.1, т.е. на маршрутизатор. Маршрутизатор, получив пакет на 22ой порт, переадресует этот пакет на 22ой порт сервера, т.е. на адрес 172.0.0.2. Сервер, получив запрос на соединение от адреса 172.0.0.3, видит, что запрос пришел от хоста из его собственной сети. И сервер шлет ответ на 172.0.0.3. И вот тут и кроется проблема: 172.0.0.3, наш ноутбук, ожидает ответ не от 172.0.0.2, а от 77.88.8.8. Получив ответ от сервера, ноутбук отбросит его, будто восклицая "дружище 172.0.0.2, я не знаю, кто ты такой, я соединяюсь с 77.88.8.8, а от тебя мне ничего не нужно".

Анимация, демонстрирующая перемещение запроса на соединение от ноутбука к серверу через маршрутизатор.

Почему же тогда перевод ноутбука в другую локальную сеть позволяет подключаться к серверу? А вот почему: сервер, получая запрос на подключение не из своей сети, отвечает на адрес шлюза по умолчанию, которым у него является адрес маршрутизатора. И пакет возвращается на маршрутизатор, откуда тот отправляет его ноутбуку, который в свою очередь ждет ответа именно от маршрутизатора.

Что же делать в такой ситуации? Добавить еще одно правило трансляции адресов, но теперь уже src-nat. Если пакет приходит на порт 22 из локальной сети и идёт на адрес сервера, то подменить адрес источника на адрес маршрутизатора. В таком случае сервер будет думать, что обращается к нему маршрутизатор, и отвечать будет тоже ему, а маршрутизатор будет возвращать ответ ноутбуку. И всё будет работать.

Ограничение на подключение USB флешек в AstraLinux

Идея такая: создать в udev правило, которое будет блокировать все флешки, серийник которых не внесён в правило.
1. Идем в /etc/udev/rules.d
2. Создаем файл 99-rem-unauth-usb.rules (имя файла можете и сами придумать, но соблюдайте правила udev)
3. Пишем в файл:

ACTION!="add", GOTO="dont_remove_usb"
ENV{ID_BUS}!="usb", GOTO="dont_remove_usb"
ENV{ID_TYPE}!="disk", GOTO="dont_remove_usb"
ENV{ID_SERIAL_SHORT}=="008D7DC64", GOTO="dont_remove_usb"
ENV{ID_BUS}=="usb", RUN+="/bin/sh -c 'echo 1 > /sys$DEVPATH/device/delete'"
LABEL="dont_remove_usb"

Немного пояснений построчно:

1. Если действие не add, то выходим (выходим путем отсылки интерпретатора командой GOTO к метке, расположенной в самом конце файла)
2. Если подключается устройство не usb, то выходим
3. Если подключенное usb устройство не типа disk, то выходим. Это важный нюанс, т.к. без этой опции отключается вся usb переферия - клавиатуры, мышки и т.д. Во всяком случае, на тестовой реальной машине было так. А вот в VirtualBox этот эффект не проявлялся.
4. Собственно проверка на серийник. Как его узнать, напишу ниже. Если параметр ID_SERIAL_SHORT у usb устройства равен указанному, то выходим - эту флешку вставлять в машину можно
5. Что же делать, если правило всё еще выполняется? Учитывая все проверки выше, это означает, что к машине подключили usb накопитель, серийник которого не прошел проверку. А это значит, что его нужно отключить. Делается это путем записывания 1 в файл sys/путь к usb устройству/device/delete. После этого флешка отключается. На тестах это выглядело как отключение питания от флешки - на ней гас светодиодный индикатор работы. 
6. Отметка, куда будет перемещен интерпретатор, если ему передать это командой GOTO 

Правило начнет работать сразу после добавления. В идеале. Для надежности и душевного спокойствия можете выполнить команды udevadm control --reload-rules и udevadm trigger или вообще перезапустить машину.

Как получить серийный номер usb накопителя?

Для этого используется команда udevadm info с параметрами -q (запрос какой информации выводить) и -n (имя устройства). В результате команда должна получить вид:

udevadm info -q all -n /dev/sdb

-q all выведет всю информацию об устройстве. В качестве альтернативы вместо all можно использовать property.
-n /dev/sdb задает имя устройства.  
Будьте с этим внимательны! У вас вместо sdb может быть sdd, sdc или что-то еще! Проверяйте, какому именно устройству присвоено sd*. Посмотреть это можно командой fdisk -l
Далее в выводе команды вас интересует значение параметра ID_SERIAL_SHORT. Это и есть серийник флешки. Его и надо подставлять в правило. Само собой, разрешенных флешек может быть несколько, просто копируйте строку, где проверяется серийник, и подставляйте в неё нужное значение.

Да, в выводе команды udevadm info присутствует параметр ID_SERIAL, но у меня по нему флеш накопители система фильтровать отказалась.

Сменить редактор по умолчанию в mc

sudo update-alternatives --config editor

Иногда при установке Linux с USB появляется ошибка вроде этой:

gfxboot.c32 not a com32r image

И дальше
boot:
И ничего не происходит.
В таком случае следует нажать клавишу TAB, это отобразит возможные команды.
Для запуска в режиме liveCD надо ввести команду live
Для установки - live-install

ntp.conf

Рабочий ntp.conf для локального ntp сервера

logconfig +clockall +clockall +syncall +clockall +sysall +syncall +clockall +peerall +sysall +syncall +clockall +clockall +syncall +clockall +sysall +syncall +clockall +peerall +sysall +syncall
#broadcastclient
server 127.127.1.1
fudge 127.127.1.1 stratum 2
driftfile /var/lib/ntp/ntp.drift
#restrict default
#restrict 127.0.0.1 mask 255.255.255.255

Запускать всё с правами администратора в Windows 7

Дома на одном из моих компов стоит Шиндоус 7. В один прекрасный день, по совершенно не понятным причинам моя локальная учетная запись, состоящая в группе администраторы, вдруг разучилась что-либо делать без "запуска от имени администратора". Некоторые игры (ради которых и стоит Win7) перестали запускаться, а из браузера невозможно было сохранить что-либо куда-либо кроме как в папку моей учетки.


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

Итак, запускаем редактор групповых политик. Пуск->Выполнить->gpedit.msc

Далее раскрываем ветку "Конфигурация Windows", там - "Параметры безопасности", оттуда в "Локальные политики" и там выбираем "Параметры безопасности" (lol).

В списке, появившемся справа, находим "Контроль учетных записей: включение режима одобрения администратором", открываем и выставляем параметр "Отключен".

После этого жмем "ОК" и делаем ребут.

Возможно, для закрепления эффекта нужно изменить режим работы учета контрольных записей, у меня он по умолчанию на нуле.

Ситуация вообще меня, если честно, не хило так выбесила. Конечно, думающая за пользователя Винда это не новость, но я как-то всё не привыкну. Больше всего, конечно, бесит тот факт, что проблема возникла у пользователя, состоящего в группе Администраторы - как еще дать пользователю прав больше, чем так? Даже в описании этой группы сказано, что она дает ВСЕ права на ВСЁ. Но оказывает, что нет. Во-вторых гугление решения по этому вопросу выдавало в основном тонны ахрененно полезных советов, суть которых сводилась к тому, что uac очень полезная хренота, что она очень вам нужна, даже если вам кажется, что нет, и вообще не стоит ее отключать, лучше на всё подряд жать правой клавишей и "запускать от имени администратора". Спасибо, вам, мелкомягкие и вам, биллибои, но я как-то сам решу как мне удобнее работать

Аутлук и кашперовский

Возникла проблема. На компьютере установлен Outlook и Кашперовский, при открытии любого входящего письма Outlook писал ошибку:

Надстройку ""Kasersky Mail Checker" (C:\Program Files\KasperskyLab\Kaspersky Anti-Virus 6.0 for Wokstation MP4\mcou.dll)" не удалось загрузить, поэтому она была отключена приложением Outlook. Обратитесь к разработчику надстройки за обновлением. Если обновления нет, удалите установленную надстройку.

В Интернете существует рекомендация по перерегистрации соответствующей dll библиотеки, однако мне этот вариант не помог, т.к. было отказано в доступе.

Пришлось искать варианты отключить надстройку. И вот как это делается:

1) Заходим в Outlook

2) В Главном Меню выбираем "Сервис", далее "Настройки управления безопасностью". 

3) В открывшемся окне находим пункт "Надстройки".

4) В самом низу будет ниспадающее меню, в котором надо выбрать "Расширение клиента Exchange" и нажать кнопку "Перейти...", находящуюся прямо справа от меню.

5) Снимаем галочку с Кашперовский Mail Checker и жмем "Ок"

6) Наслаждаемся отсутствием надоедливых сообщений.

Возможно данная процедура влияет на безопасность.