Перейти к контенту

[Решено] Нет подключения к защищенной сети с Vipnet Client 4.1 Linux 


Рекомендуемые сообщения

Установка прошла успешно. Демон vipnet запускается без ошибок, судя по логам и остальные успешно стартуют и работают. Но пинги в защищённую сеть не идут. 

На порту 55777/udp должен какой-то сервис работать? Хотя этот порт и прописан в iplir.conf, netstat -anup его не показывает. 

В логах только обмен upd пакетами с Координатором по порту 2046 раз в минуту (это если смотреть только шифрованный трафик). Блокированных пакетов нет. 

Хост за МЭ. Пробовал статический NAT, но после запуска конфиг iplir.conf меняется на использование динамического. Не знаю, это он сам или настройки сети такие? 

Mar 13 06:28:10 centos64 iplircfg[26665]: Force change to DNAT mode for the Client.
Mar 13 06:28:10 centos64 iplircfg[26665]: Reset fixfirewall in Dynamic NAT proxy mode.
Mar 13 06:28:10 centos64 iplircfg[26665]: Change ProxyId to FFFFFFFE because of DYNAMIC firewall mode.

Какие есть возможности проверить работу клиента на хосте, чтобы точно знать, что проблема на стороне Координатора, а не хоста с клиентом на борту?

ViPNet Client 4.1.4 (10954). Интернет работает. 

Изменено пользователем supper0
Пометка [Решено] в теме
Ссылка на комментарий
Поделиться на других сайтах

3 часа назад, KIV сказал:

Время проверьте и iplir view посмотрите на координаторе.

Время стоит правильное, московский часовой пояс. Разве Клиент и Координатор должны работать в одном часовом поясе? Настраивал время вручную через date, но в инструкции ни слова про настройку времени.

Сам не могу посмотреть ничего на Координаторе, а администратор не сильно торопится помогать.

Ссылка на комментарий
Поделиться на других сайтах

1 час назад, supper0 сказал:

Разве Клиент и Координатор должны работать в одном часовом поясе?

Нет. Но часовой пояс и время должны быть правильные иначе пакеты будут блокироваться (при расхождении более чем на 2 часа).

 

12 часов назад, supper0 сказал:

Какие есть возможности проверить работу клиента на хосте, чтобы точно знать, что проблема на стороне Координатора, а не хоста с клиентом на борту?

iplir view - убедитесь, что пакеты от Вашего узла уходят. Далее необходимо смотреть на координаторе, что пакеты доходят.

Ссылка на комментарий
Поделиться на других сайтах

1 час назад, denis.r сказал:

Нет. Но часовой пояс и время должны быть правильные иначе пакеты будут блокироваться (при расхождении более чем на 2 часа).

 

iplir view - убедитесь, что пакеты от Вашего узла уходят. Далее необходимо смотреть на координаторе, что пакеты доходят.

В журнале нет блокированных пакетов, в статистике iplir info Encrypted packets dropped всегда нулевое значение. Если ставить регистрацию всех пакетов, то видно, что есть исходящие icmp к Координатору, но нет ответа и есть исходящие udp 2046 а даже входящие по этом порту. Больше трафика в журнале нет, пинги не ходят, в открытую сеть пинги ходят.

Меня вот еще момент смущает, что нет процесса на 55777/udp это так и должно быть? Посмотрите netstat -anu у кого Координатор или Клиент на линуксе.

Ссылка на комментарий
Поделиться на других сайтах

опрос идет именно по порту  udp 2046, а инкапсуляция в порт 55777/udp происходит, когда пойдет зашифрованный трафик.

Ссылка на комментарий
Поделиться на других сайтах

9 минут назад, Rinya сказал:

Вопрос: У вас в   iplir.conf  у координатора прописан адрес? (внешний адрес координатора)

 

Да, там несколько адресов в параметрах ip=, accessip=, firewallip=, accessiplist=. Есть там и реальный адрес из открытой сети, но он не пингуется и с влюченным випнетом, и с выключенным (хотя это и не показатель, да).

Пробовал настроить на статический NATб но при запуске iplir выдается предупреждение о принудительной смене режима и меняется конфиг. Это почему так происходит? И после этого в секции [dynamic] firewallip= уже не адрес моего маршрутизатора, а серый адрес хоста на eth0 (192.168.X.X). Это разве нормально? В инструкции написано, что параметры определяются автоматически по опросу других участников, но внешний адрес нигде в конфиге iplir.conf не задействован.

Демон mftpd постоянно в состоянии connecting

# ps aux |grep mftp
root      3354  0.7  0.6 230832 12132 ?        Ssl  10:38   0:31 mftpd: connecting (single)

 

Ссылка на комментарий
Поделиться на других сайтах

По поводу переключения со статики в динамику - скорее всего так настроено.

Обычно (в большинстве случаев) соединение происходит стабильно при динамике.

попробуйте в секции  [dynamic] прописать  firewallip= (внешний адрес координатора).

А что прописано в данной секции в параметре forward_id?

 

Ссылка на комментарий
Поделиться на других сайтах

38 минуты назад, Rinya сказал:

По поводу переключения со статики в динамику - скорее всего так настроено.

Обычно (в большинстве случаев) соединение происходит стабильно при динамике.

попробуйте в секции  [dynamic] прописать  firewallip= (внешний адрес координатора).

А что прописано в данной секции в параметре forward_id?

 

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

firewallip= менял на свой внешний ip, и на адрес Координатора - не работает.

forward_id установлен ID Координатора в защищенной сети. Этот же ИД выше есть в секции [id] для Координатора.

 

Ребята, подскажите как получить доступ к веб-интерфейсу из открытой сети? Клиент установлен на сервере без графики и доступ только по ssh.

Ссылка на комментарий
Поделиться на других сайтах

Всем спасибо за подсказки, проблема решена! 

Ожидаемо, проблема была на Координаторе. Забыли поднять туннель и дали не тот адрес сервиса в защищенной сети, с которым предстоит работать. Удивительно. 

 

mftpd сменил статус, а порта 55777/udp в netstat я так и не наблюдаю. Пинги до Координатора ходят, и пакеты в обе стороны появились в журнале. 

#  ps aux |grep mftp
root      3622  0.8  0.7 231708 14244 ?        Ssl  14:43   2:43 mftpd: idle (single)

# netstat -anup
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address               Foreign Address             State       PID/Program name   
udp        0      0 0.0.0.0:39660               0.0.0.0:*                               3623/algd           
udp        0      0 127.0.0.1:10092             0.0.0.0:*                               3607/failoverd      
udp        0      0 0.0.0.0:2046                0.0.0.0:*                               3620/iplircfg       
udp     9768      0 0.0.0.0:2048                0.0.0.0:*                               3620/iplircfg       
udp        0      0 0.0.0.0:55330               0.0.0.0:*                               3620/iplircfg       
udp        0      0 0.0.0.0:39971               0.0.0.0:*                               3622/mftpd          
udp        0      0 0.0.0.0:38716               0.0.0.0:*                               3623/algd           
udp        0      0 0.0.0.0:59717               0.0.0.0:*                               3623/algd           
udp        0      0 0.0.0.0:51547               0.0.0.0:*                               3623/algd           

 

Ссылка на комментарий
Поделиться на других сайтах

Присоединиться к обсуждению

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

Гость
Ответить в этой теме...

×   Вы вставили отформатированный текст.   Удалить форматирование

  Допустимо не более 75 смайлов.

×   Ваша ссылка была автоматически заменена на медиа-контент.   Отображать как ссылку

×   Ваши публикации восстановлены.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.

×
×
  • Создать...

Важная информация

Продолжая пользоваться сайтом вы принимаете Условия использования.