Strongswan пересылка трафика между двумя туннелями IPsec, где один является хостом

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

Длинный ответ: вы неправильно поняли значение и синтаксис директивы AllowUsers .

Из справочной страницы:

 AllowUsers
         This keyword can be followed by a list of user name patterns,
         separated by spaces.  If specified, login is allowed only for
         user names that match one of the patterns.  Only user names are
         valid; a numerical user ID is not recognized.  By default, login
         is allowed for all users.  If the pattern takes the form
         USER@HOST then USER and HOST are separately checked, restricting
         logins to particular users from particular hosts.  HOST criteria
         may additionally contain addresses to match in CIDR
         address/masklen format.  The allow/deny directives are processed
         in the following order: DenyUsers, AllowUsers, DenyGroups, and
         finally AllowGroups.

         See PATTERNS in ssh_config(5) for more information on patterns.

Обратите внимание на второе предложение: «Если указано, вход в систему разрешен только для имен пользователей, которые соответствуют одному из шаблонов »

Когда вы добавили второго пользователя (и только второго) кому: AllowedUsers вы заблокировали всех остальных пользователей. Включая рут. И все, что вы неправильно сконфигурировали в ssh или ошибочно набрали при изменении пароля второго пользователя, не позволяет вам войти в систему как этот пользователь.

На самом деле невозможно получить дополнительную информацию о том, почему вы не можете войти в систему; в конце концов, ssh не может определить, являетесь ли вы враждебным субъектом, пытающимся подобрать пароль, или законным пользователем, который забыл свой настоящий пароль, и давая прежние полезные советы относительно того, как успешно войти в систему было бы что-то вроде риска для безопасности.

Если вы используете стандартный unix openSSH, вы можете попробовать использовать ssh -vvv для подключения и посмотреть, есть ли в рукопожатии что-нибудь, что подсказывает, что вы делаете неправильно, кроме неправильного ввода учетных данных. , но учитывая, что root действительно работал, пока вы не захлопнули дверь перед собой, эта часть , вероятно, не является проблемой.

2
13.04.2017, 15:36
1 ответ

Это выглядит неправильно:

20:42:28.897990 IP AA.AA.AA.AA > 192.168.250.129: ICMP echo request, id 39774, seq 0, length 64

Почему должен быть ICMP с общедоступного IP-адреса A мобильному клиенту, если A просто пересылает трафик B? То, что вы ожидаете, - это пакет ESP с публичным IP-адресом A, но определенно не ICMP.

Возможно, существует правило NAT для A? В таком случае обязательно используйте модуль policy , чтобы исключить трафик, соответствующий политике IPsec, из действующего правила NAT. В основном добавьте что-то вроде этого перед фактическим правилом NAT (также объясненным в strongSwan wiki ):

iptables -t nat -A POSTROUTING -s 192.168.1.0/24,192.168.2.0/24,192.168.250.0/24 -o eth0 -m policy --dir out --pol ipsec -j ACCEPT
2
27.01.2020, 22:10

Теги

Похожие вопросы