Настраивал сегодня openvpn

[dil]

Подключился с клиентской машинки к серверу, посмотрел в тамошний лог, а.. соединения на сервер приходят со 127.0.0.1:

Sep 11 12:19:31 srv ovpnsrv[16954]: 127.0.0.1:42277 [plex7] Peer Connection Initiated with [AF_INET]127.0.0.1:42277
Sep 11 12:19:31 srv ovpnsrv[16954]: plex7/127.0.0.1:42277 OPTIONS IMPORT: reading client specific options from: /etc/openvpn/ccd/plex7
Sep 11 12:19:31 srv ovpnsrv[16954]: plex7/127.0.0.1:42277 MULTI: Learn: 10.20.30.2 -> plex7/127.0.0.1:42277
Sep 11 12:19:31 srv ovpnsrv[16954]: plex7/127.0.0.1:42277 MULTI: primary virtual IP for plex7/127.0.0.1:42277: 10.20.30.2
Sep 11 12:19:32 srv ovpnsrv[16954]: plex7/127.0.0.1:42277 PUSH: Received control message: 'PUSH_REQUEST'
Sep 11 12:19:32 srv ovpnsrv[16954]: plex7/127.0.0.1:42277 send_push_reply(): safe_cap=960
и т.д...

Машинки физически разные, и хотя в данном случае они соединялись непосредственно через wifi, но никаких дополнительных туннелей между ними нету, прокси-серверов тоже нету, а в настройках клиента указан публичный адрес сервера. Кто тут грамотные системные администраторы – попробуйте догадаться, как такое может получиться ;)

Это не проблема, а просто загадка. Я-то ответ знаю.

Оригинал этой записи в личном блоге.

Comments

Re: соединения на сервер приходят со 127.0.0.1

[dememax]

Соединения приходят, но через локальный файрвол/антивирус?

Re: соединения на сервер приходят со 127.0.0.1

[dil]

Файрвол там есть, но он NATит только исходящие соединения с локальных адресов в публичный, и обратно, а 127.0.0.1 не трогает.
Антивируса вовсе нет.

Re: соединения на сервер приходят со 127.0.0.1

[dememax]

Эх, плохой из меня сисадмин. :-(

Re: соединения на сервер приходят со 127.0.0.1

[dil]

Подсказочка: http://dil.dreamwidth.org/1549209.html?thread=9583513#cmt9583513

[mcjabberwock]

Ну как-как? Небось роутинг через задницу проброшен, линухоиды это любят ;)
ЗЫ: я помню, что с меня мини-сочинение "за что я ненавижу линух", но всё никак свободное время с настроением не совпадает.

[dil]

Не-а, никаких хитростей с роутингом там нету. Только NAT с приватных адресов локальной сетки в публичный IP для исходящих соединений. А 127.0.0.1 он не трогает.

[bsv9.livejournal.com]

Это он в лог резолвит IP в имя "127.0.0.1" ?

[dil]

Не, это вправду 127.0.0.1. Хотя там же есть местный DNS-сервер, который знает имена для приватных адресов из локальной сетки, но такого имени там нету. А openvpn всё равно в лог только адреса пишет, не ресолвит их в имена.

[lazyboa.livejournal.com]

xinetd redirect=127.0.0.1 1194
Правда в упор не понимаю, какой смысл редиректить в самого себя.

[dil]

xinetd там вовсе нету, и смысла в таком редиректе тоже нету.
Но ежели клиент идёт на внешний адрес, а сервер получает запрос с локального, значит там и правда что-то похожее есть. А вот что? ;)

[dil]

Короче, правильный ответ: sslh, который принимает соединения на необычном порту, и ssh прокидывает на 22 порт, а ssl - на 1194.

[lazyboa.livejournal.com]

Ой, openvpn через tcp. И как, лаг сильно больше?

[dil]

Какой-такой лаг? Не всё ли равно, используется ли в VPN'е TCP, UDP, ESP, или ещё что?

[lazyboa.livejournal.com]

Все равно пока это не TCP. Из-за того, что он stateful и гарантирует доставку пакетов в порядке отправления, ему приходится задерживать пакеты в окне приема. TCP-over-TCP использует уже два окна на разных уровнях, так что если в пути случаются потери, перемешивание пакетов или большой исходный лаг, то вложенный TCP может уже никогда не выйти из таймаута.