А не в этом ли причина? Mon Jun 10 11:49:51 2013 us=567351 *Data Channel MTU* parms [ L:1544 *D:1450* EF:44 EB:135 ET:0 EL:0 AF:3/1 ] Mon Jun 10 11:49:51 2013 us=567420 *Local Options String*: 'V4,dev-type tun,link-mtu 1544,*tun-mtu 1500*,proto TCPv4_CLIENT,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' Mon Jun 10 11:49:51 2013 us=567456 Expected Remote Options String: 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto
Про MTU вам уже писали. Правда раз на сервере поменять не можете - попробуйте поменять на клиенте. 10 июня 2013 г., 12:15 пользователь Alex Dubinin <[email protected]>написал: > 10.06.2013 12:00, Eugene Berdnikov пишет: > > Ну покажите выдачу nmap в подтверждение, мне даже интересно стало... > > :) А все остальные программы это ни разу не инструменты для диагностики. > Что-то я вообще начинаю путаться в Ваших сообщенях. > Проблемы 2: > 1. не ко всем серверам организации есть коннект. в данном случае просто > не работает VPN и всё здесь. при этом с этим же сервером винда отлично > поднимает коннект. в данном контексте nmap etc не имеет смысле > приводить, т.к. просто нет тоннеля! какие подтверждения Вам нужны? вывод > ip a? чтобы Вы убедились что тоннеля просто нет! > 2. если к серверу организации поднимается vpn, то впоследствие не все > порты наружу доступны. мне например нужны порты 1521,2222,5222 etc - все > они при работающем VPN-тоннеле недоступны! в подтверждение этого я > привел nmap в первом сообщении. хотя при этом сайты открываются и т.д. > > В протоколе TCP слово "reset" имеет вполне конкретный смысл и означает > > получение от пира пакета с битом RST. Должна быть возможность > > обратиться к службе поддержки этого сервера. Иначе работа с ним это > > риск для бизнеса. > Лог с verb 4: > > Mon Jun 10 11:49:51 2013 us=565788 LZO compression initialized > Mon Jun 10 11:49:51 2013 us=565993 Control Channel MTU parms [ L:1544 > D:140 EF:40 EB:0 ET:0 EL:0 ] > Mon Jun 10 11:49:51 2013 us=566079 Socket Buffers: R=[87380->131072] > S=[16384->131072] > Mon Jun 10 11:49:51 2013 us=567205 TUN/TAP device tun1 opened > Mon Jun 10 11:49:51 2013 us=567276 TUN/TAP TX queue length set to 100 > Mon Jun 10 11:49:51 2013 us=567351 Data Channel MTU parms [ L:1544 > D:1450 EF:44 EB:135 ET:0 EL:0 AF:3/1 ] > Mon Jun 10 11:49:51 2013 us=567420 Local Options String: 'V4,dev-type > tun,link-mtu 1544,tun-mtu 1500,proto TCPv4_CLIENT,comp-lzo,cipher > BF-CBC,auth SHA1,keysize 128,key-method 2,tls-server' > Mon Jun 10 11:49:51 2013 us=567456 Expected Remote Options String: > 'V4,dev-type tun,link-mtu 1544,tun-mtu 1500,proto > TCPv4_SERVER,comp-lzo,cipher BF-CBC,auth SHA1,keysize 128,key-method > 2,tls-client' > Mon Jun 10 11:49:51 2013 us=567514 Local Options hash (VER=V4): '179ea788' > Mon Jun 10 11:49:51 2013 us=567557 Expected Remote Options hash > (VER=V4): '0102d9ab' > Mon Jun 10 11:49:51 2013 us=567602 Attempting to establish TCP > connection with [AF_INET]IP:PORT [nonblock] > Mon Jun 10 11:49:52 2013 us=567913 TCP connection established with > [AF_INET]IP:PORT > Mon Jun 10 11:49:52 2013 us=567980 TCPv4_CLIENT link local: [undef] > Mon Jun 10 11:49:52 2013 us=568017 TCPv4_CLIENT link remote: > [AF_INET]IP:PORT > Mon Jun 10 11:49:52 2013 us=845290 Connection reset, restarting [0] > Mon Jun 10 11:49:52 2013 us=845545 TCP/UDP: Closing socket > Mon Jun 10 11:49:52 2013 us=845651 Closing TUN/TAP interface > Mon Jun 10 11:49:52 2013 us=862037 SIGUSR1[soft,connection-reset] > received, process restarting > Mon Jun 10 11:49:52 2013 us=862079 Restart pause, 5 second(s) > > Обратился, но т.к. контора не имеет подчинения нам - они могут: а) > сказать что у них и так все норм (как это обычно бывает); б) не ответить > совсем. > > В логах сервера. Авторы openvpn не предусмотрели передачу какого-либо > > статус-кода или сообщения клиенту в этом случае. Они, конечно, > > редиски, но достаточно коммуникабельны и даже принимают патчи. :) > Пробовал запускать с verb 4 - более подробной информации не появилось. > -- ________________ Andrey V Ivanov
