krosh

Попробуйте в первой строке заменить ROM на FROM.

nginx не может проксировать трафик на апстрим.
В default.conf замените project_core на core, project_web -> web.

При защите персональных данных, начните с того, что составьте Модель угроз. Без этого документа, у вас нет защиты персональных данных. Не можете его составить, не нужно ничего дальше предпринимать, только больше запутаетесь и будете жить в уверенности, что все сделали, а когда прижмет - все окажется иначе.

Какая угроза (или группа угроз) имеет отношение к каналу связи между серверами?

После этого ищите меры защиты или компесационные меры. Приказ ФСТЭКа № 21 тоже нужно будет изучить.

В целом, если мы рассматриваем типичную ситуацию в ВАККУУМЕ, то при передаче конфиденциальных данных через открытые сети, то единственная мера защиты - сертифицированная криптограция. А это или ВПН или два криптошлюза с туннелем между площадками. Но прежде чем дойти до этого, нужно выяснить, а в ЦОДе все остальные меры защиты уже приняты, чтобы вы там могли спокойно и легально обрабатывать ПДн?

Если 192.168.1.1 это другой хост - замените INPUT на FORWARD. Все, что за пределами локального хоста, фильтруется в цепочке FORWARD.

Если 192.168.1.1 та же самая машина, то --dport 22 -> --dport 2222 в цепочке INPUT Только в этом случае не ясно, зачем использовать iptables, когда порт в настройках можно сменить.

Правильно - хранить закрытую часть ключа только на физических токенах, не на сервере, не в реестре. Особенно если речь про ГОСТ.

Какая цель вашего мероприятия - учет или мобильное использование? Если сертификатов разумное количество, то дальше обычной таблицы не стоит заморачиваться. Главное, что вам нужно мониторить - это сроки окончания сертификата и кому он выдан. При учете ЭП нужно записать и имя субъекта, и имя пользователя, кто использует ЭП (так делать не нужно, но так бывает), и номер носителя/токена, а значит носители тоже нужно отдельно учитывать.

Закупите токены в офисы и сделайте копий (это тоже не правильно, но позволит работать в разных местах). А еще лучше выдать ЭП каждому ответственному и доверенность на вид работы.

iptables-save > tmp.save
sed -i 's/AAA(рандомное число)AAA/AAAA(нужное число)AAA/g' tmp.save
iptables-restore < tmp.save

Вы хотите в сетях разобраться или работать?

Если работать и больше ничего. Начните с https://www.whonix.org/. Там есть гейтвей и воркстейшен. Простая инструкция. Потом подпимите впн-клиента на гейтвее, как на обычном линуксе и все будет работать.

Если разобраться.

1. Делаем 2 ВМ: Шлюз, вПК. В настройках вирт. адаптера объединяем их в один сегмент локальной сети. Шлюз - 2 адаптера: первый - внешний пусть пока будет НАТ или мост, если у вас есть домашняя сеть с роутером; второй - локальный, там указываете имя сегмента вирт. локальной сети. И Виртуалбокс и ВМВарь это умеют.

2. Настройте Шлюз как обычно, чтобы он пускал в сеть вПК. Это класическая тема, ищите мануалы в сети snat + forwarding. Как настроите и проверите, можно дальше двигаться.

3. На Шлюзе настраивайте впн-клиент до внешнего впн-сервера. Проверяте чтобы локально работало через впн-сервер и дефолтовый маршрут был на впн-сервер. Логично, что тогда и вПК будет ходить в инет также. Ему-то пофиг, что там с трафиком после того, как он отправил его своему дефолтовому гейтвею.

4. Научиться контролировать статус соединения, чтобы не было утечки, когда впн на Шлюзе не работает. И запросы к ДНС или на Шлюзе обрабатывались, или через впн шли.

5. И почему Дебиан 9.9? Берите уже 10-ку.

Весь трафик впн-сервера проходит через цепочку FORWARD, там занимайтесь фильтрацией. В этом контексте он становится маршрутизатором, а на эту тему достаточно материала в поиске. Предполагая, что tun0 - интерфейс для впн-клиентов, а eth0 - в интернет, то можно начать со следующих правил.

iptables -P FORWARD DROP
iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -m comment --comment "РАЗРЕШЕНО Установленные соединения" -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -s 192.168.0.100 -p udp -m udp --dport 53 -m comment --comment "РАЗРЕШЕНО DNS/udp для 192.168.0.100" -j ACCEPT
iptables -A FORWARD -i tun0 -o eth0 -s 192.168.0.100 -m conntrack --ctstate NEW -m comment --comment "РАЗРЕШЕНО Интернет для 192.168.0.100" -j ACCEPT

Возможно правило про ДНС лишнее, не помню как OpenVPN работает с днс-запросами. Попробуйте для начала вовсе без него.

l2tp/ipsec - это протоколы, не версия сервиса. Скорей всего вы используете StrongSwan. Переходите на IKEv2, уже все правильные ребята так давно сделали, это проще в поддержке чем l2tp.

Вам нужно добавить два статических маршрута на дебиан сервере и на микротике.

Дебиан: ip route add 172.30.0.0/24 via eth0
Микротик: ip route add 192.168.42.0/24 via eth0

Команды написаны условно. eth0 - вирт. адаптер впн-подключения. Не забудьте разрешить форвард-трафик на обех роутерах, чтобы трафик до подсети проходил. В инет трафик будет идти по дефолтовому маршруту, а в прописанную подсеть через интерфейс впн-подключения.

У вас нет критерия поиска сертификата.
Попробуйте:
cryptcp -dn test -nochain -vsignf -mroot test.txt

Суть REDSOCKS проксировать весь трафик, а не только определенный - 80 порт, как у вас.

Почитайте: Как раздать интернет на вторую сетевую карту? и Настройка Bind в паре с Redsocks?

Если это не помогает, то в чем же вопрос?

https://bitwarden.com/#organizations

Если исходить из предположения, что роутер, днс-сервер и хост .1.22 три разных устройства и они связаны в локальную сеть коммутатором.

Обмен трафиком в сегменте сети происходит по протоколу Ethernet, поиск хостов - ARP. Трафик адресуется напрямую хосту используя mac-адрес, а не ip-адрес. Поэтому трафик между хостами локальной сети а) просто не доходит до роутера, т.к. не адресуется ему, т.к. при отправке выставляется mac-адрес хоста назначения - днс-сервера. Роутер тоже получает этот пакет, но т.к. mac-адрес не совпадает, он его отбрасывает (поэтому есть еще неразборчивый режим - Promiscuous mode, который позволяет захватывать любой трафик, но это не наш случай) и б) никакие правила фильтрации не используются (можете проверить полностью заблокировав цепочку FORWARD).

Вы пробовали на хосте 192.168.1.22 менять настройки днс-сервера?
Попробуйте отправить запрос напрямую, например так:
nslookup ya.ru 1.1.1.1
nmap -p U:53 192.168.1.11

если ответа не будет - идите разбирайтесь на 192.168.1.11.
Порт открыт? Может настройки днс-сервера поменять, чтобы он висел не на локальном интерфейсе, а на 192.168.1.11?

У вас маршрутизатор или рабочая станция/рядовой сервер? Примем ситуацию с хостом-клиентом.

Меняйте маршрут по умолчанию после того, как будет поднят впн-туннель. В некоторых клиентах можно сразу в конфиг это прописать, или напишите отдельный скрипт с ip route add, который будет запускаться при старте впн-туннеля. Можно или default gw менять, либо первой строчкой ставить доступ в сеть 0.0.0.0/0 через интерфейс впн-туннеля.

Пользуйтесь цепочкой FORWARD для фильтрации проходящего мимо трафика.

Не знаю, что у вас там сейчас, но правильное решение должно содержать такие правила:

iptables -P FORWARD DROP
iptables -A FORWARD -m state --state RELATED,ESTABLISHED -m comment --comment "РАЗРЕШЕНО Установленные соединения" -j ACCEPT
iptables -A FORWARD -s 192.168.0.0/24 -o eth0 -m comment --comment "РАЗРЕШЕНО Локальная сеть, основной канал" -j ACCEPT
iptables -A FORWARD -s 192.168.0.101 -o rth1 -m comment --comment "РАЗРЕШЕНО Человек первый хороший, резервный канал" -j ACCEPT
iptables -A FORWARD -s 192.168.0.102 -o rth1 -m comment --comment "РАЗРЕШЕНО Человек второй хороший, резервный канал" -j ACCEPT

1. DNAT iptables, как написали выше. И про обратные правила SNAT и в FORWARD не забудьте.

2. haproxy в целом, может работать так, как вам нужно хотя и не предназначена для этого. Настройка простая, попробуйте.

Запрет трафика с одного на другой интерфейс:
iptables -A FORWARD -o tun0 -i tun2 -j REJECT

Если надо запретить клиенту идти на другой впн-сервер:

iptables -A FORWARD -s 10.10.0.0/24 -i tun2 -j REJECT

Или просто отключите форвардинг на сервере:
sysctl -w net.ipv4.ip_forward=0или в /etc/sysctl.conf

Наброски и рисунок, Кэти Джонсон
www.ozon.ru/context/detail/id/5934992

Много практики по разным аспектам рисунка. В основном там про карандашные наброски и простые рисунки.

SMB can run on top of the session (and lower) network layers in several ways:

Directly over TCP, port 445;[5]
Via the NetBIOS API, which in turn can run on several transports:[6]
On UDP ports 137, 138 & TCP ports 137, 139 (NetBIOS over TCP/IP);
On several legacy protocols such as NBF, IPX/SPX.

https://en.wikipedia.org/wiki/Server_Message_Block

Я бы начал с такого набора:

iptables -t nat -A PREROUTING -p udp --dport 137 -j REDIRECT --to-port 3137
iptables -t nat -A PREROUTING -p udp --dport 138 -j REDIRECT --to-port 3138
iptables -t nat -A PREROUTING -p tcp --dport 139 -j REDIRECT --to-port 3000
iptables -t nat -A PREROUTING -p tcp --dport 445 -j REDIRECT --to-port 3333
iptables -A INPUT -m conntrack --ctstate NEW -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state –state NEW -p udp –dport 137 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state –state NEW -p udp –dport 138 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state –state NEW -p tcp –dport 139 -j ACCEPT
iptables -A INPUT -s 192.168.1.0/24 -m state –state NEW -p tcp –dport 445 -j ACCEPT

Таблица nat - сам редирект, а ниже в INPUT - открытие портов. Возможно и порты редиректа нужно будет открыть.

Если норм, то можно пробовать оставить только 445/tcp.