Подскажите с настройкой клиент-банка…



  • Здравствуйте. Господа, такая проблема, почти что беда :) Есть у пользователей клиент-банк, который соединяется с сервером через програмку Stunnel. Связка выходит такая: на пользовательском ПК запускается stunnel в режиме клиента, который слушает локальный сокет. Запускается КБ, соединяется с локальным сокетом Stunnel. Stunnel начинает устанавливать подключение к своей серверной части в банке. Устанавливает. И начинает обмен данными SSL… Тут-то и происходит бяка: на этапе приветствия клиент stunnel отваливается от сервера, с сообщением:

    2010.06.07 10:07:47 LOG7[2768:560]: SSL state (connect): before/connect initialization
    2010.06.07 10:07:47 LOG7[2768:560]: SSL state (connect): SSLv3 write client hello A
    2010.06.07 10:07:47 LOG3[2768:560]: SSL_connect: Peer suddenly disconnected

    я создавал правила вида:

    TCP/UDP  10.6.0.73  *  111.111.111.11  2215  *

    Где 111.111.111.11 IP адрес банка и 2215 порт на котором слушает серверная часть Stunnel, т.е. разрешаем подключаться 10.6.0.73 к узлу 111.111.111.11 на порт 2215.
    В логах PF при этом наблюдались такие сообщения:

    pf: 630377 rule 102/0(match): block out on xl0: (tos 0x0, ttl 127, id 36413, offset 0, flags [none], proto TCP (6), length 181) 192.168.11.12.57297 > 111.111.111.11.2214: FP, cksum 0x4981 (correct), 1972950361:1972950502(141) ack 1550186680 win 65535

    Я ухватился за это block out on xl0 и насоздавал всяких разрешающих правил - не помогло. Подскажите как быть в этой ситуации?



  • Что за интерфейс xl0 ? Что за IP 192.168.11.12 ? Покажите правила/NAT.



  • @dvserg:

    Что за интерфейс xl0 ? Что за IP 192.168.11.12 ? Покажите правила/NAT.

    Извиняюсь. xl0 - это WAN интерфейс. IP 192.168.11.12 - им я заменил свой внешний ип чтобы не светить :)
    правила:




  • А прямо сюда можно прицепить? У меня не открывается ссылка (ниже Additional options см)



  • конечно
    lan rules
    nat






  • wan rules




  • С лана вроде все ОК, а на Wan у Вас параноя- сделайте общее правило
    "Разрешить все tcpudp из LAN subnet to any".



  • @dvserg:

    С лана вроде все ОК, а на Wan у Вас параноя- сделайте общее правило
    "Разрешить все tcpudp из LAN subnet to any".

    Сделал правило, но увы не помогло. Те же сообщения в логах:

    Jun 7 14:05:49 pf: 204885 rule 100/0(match): block out on xl0: (tos 0x0, ttl 127, id 17311, offset 0, flags [DF], proto TCP (6), length 181) 192.168.11.12.31954 > 111.111.111.11.2214: FP, cksum 0x15d9 (correct), 2257198530:2257198671(141) ack 1927692587 win 65535




  • А отключить 2 верхних правила?



  • Отключал, это я сделал в первую очередь :) Ни к каким положительным результатам не приводит. Я уточню, коннект к серверу банка происходит. Вот полный лог stunnel клиента:

    2010.06.07 10:06:38 LOG5[2768:3616]: Reading configuration from file stunnel.conf
    2010.06.07 10:06:38 LOG7[2768:3616]: Snagged 64 random bytes from C:/.rnd
    2010.06.07 10:06:38 LOG7[2768:3616]: Wrote 1024 new random bytes to C:/.rnd
    2010.06.07 10:06:38 LOG7[2768:3616]: RAND_status claims sufficient entropy for the PRNG
    2010.06.07 10:06:38 LOG7[2768:3616]: PRNG seeded successfully
    2010.06.07 10:06:38 LOG7[2768:3616]: Certificate: stunnel.pem
    2010.06.07 10:06:38 LOG7[2768:3616]: Certificate loaded
    2010.06.07 10:06:38 LOG7[2768:3616]: Key file: stunnel.pem
    2010.06.07 10:06:38 LOG7[2768:3616]: Private key loaded
    2010.06.07 10:06:38 LOG7[2768:3616]: SSL context initialized for service pop3s
    2010.06.07 10:06:38 LOG7[2768:3616]: Certificate: stunnel.pem
    2010.06.07 10:06:38 LOG7[2768:3616]: Certificate loaded
    2010.06.07 10:06:38 LOG7[2768:3616]: Key file: stunnel.pem
    2010.06.07 10:06:38 LOG7[2768:3616]: Private key loaded
    2010.06.07 10:06:38 LOG7[2768:3616]: SSL context initialized for service imaps
    2010.06.07 10:06:38 LOG7[2768:3616]: Certificate: stunnel.pem
    2010.06.07 10:06:38 LOG7[2768:3616]: Certificate loaded
    2010.06.07 10:06:38 LOG7[2768:3616]: Key file: stunnel.pem
    2010.06.07 10:06:38 LOG7[2768:3616]: Private key loaded
    2010.06.07 10:06:38 LOG7[2768:3616]: SSL context initialized for service ssmtp
    2010.06.07 10:06:38 LOG7[2768:3616]: Certificate: stunnel.pem
    2010.06.07 10:06:38 LOG7[2768:3616]: Certificate loaded
    2010.06.07 10:06:38 LOG7[2768:3616]: Key file: stunnel.pem
    2010.06.07 10:06:38 LOG7[2768:3616]: Private key loaded
    2010.06.07 10:06:38 LOG7[2768:3616]: SSL context initialized for service client
    2010.06.07 10:06:38 LOG5[2768:3616]: Configuration successful
    2010.06.07 10:06:38 LOG5[2768:3616]: No limit detected for the number of clients
    2010.06.07 10:06:38 LOG7[2768:3616]: FD=148 in non-blocking mode
    2010.06.07 10:06:38 LOG7[2768:3616]: Option SO_REUSEADDR set on accept socket
    2010.06.07 10:06:38 LOG7[2768:3616]: Service pop3s bound to 0.0.0.0:995
    2010.06.07 10:06:38 LOG7[2768:3616]: Service pop3s opened FD=148
    2010.06.07 10:06:38 LOG7[2768:3616]: FD=136 in non-blocking mode
    2010.06.07 10:06:38 LOG7[2768:3616]: Option SO_REUSEADDR set on accept socket
    2010.06.07 10:06:38 LOG7[2768:3616]: Service imaps bound to 0.0.0.0:993
    2010.06.07 10:06:38 LOG7[2768:3616]: Service imaps opened FD=136
    2010.06.07 10:06:38 LOG7[2768:3616]: FD=160 in non-blocking mode
    2010.06.07 10:06:38 LOG7[2768:3616]: Option SO_REUSEADDR set on accept socket
    2010.06.07 10:06:38 LOG7[2768:3616]: Service ssmtp bound to 0.0.0.0:465
    2010.06.07 10:06:38 LOG7[2768:3616]: Service ssmtp opened FD=160
    2010.06.07 10:06:38 LOG7[2768:3616]: FD=168 in non-blocking mode
    2010.06.07 10:06:38 LOG7[2768:3616]: Option SO_REUSEADDR set on accept socket
    2010.06.07 10:06:38 LOG7[2768:3616]: Service client bound to 0.0.0.0:1123
    2010.06.07 10:06:38 LOG7[2768:3616]: Service client opened FD=168
    2010.06.07 10:06:38 LOG5[2768:3616]: stunnel 4.33 on x86-pc-mingw32-gnu with OpenSSL 1.0.0 29 Mar 2010
    2010.06.07 10:06:38 LOG5[2768:3616]: Threading:WIN32 SSL:ENGINE Sockets:SELECT,IPv6
    2010.06.07 10:07:47 LOG7[2768:604]: Service client accepted FD=240 from 127.0.0.1:2084
    2010.06.07 10:07:47 LOG7[2768:604]: Creating a new thread
    2010.06.07 10:07:47 LOG7[2768:604]: New thread created
    2010.06.07 10:07:47 LOG7[2768:560]: Service client started
    2010.06.07 10:07:47 LOG7[2768:560]: FD=240 in non-blocking mode
    2010.06.07 10:07:47 LOG7[2768:560]: Option TCP_NODELAY set on local socket
    2010.06.07 10:07:47 LOG5[2768:560]: Service client accepted connection from 127.0.0.1:2084
    2010.06.07 10:07:47 LOG7[2768:560]: FD=276 in non-blocking mode
    2010.06.07 10:07:47 LOG6[2768:560]: connect_blocking: connecting 194.143.138.138:2214
    2010.06.07 10:07:47 LOG7[2768:560]: connect_blocking: s_poll_wait 194.143.138.138:2214: waiting 10 seconds
    2010.06.07 10:07:47 LOG5[2768:560]: connect_blocking: connected 194.143.138.138:2214
    2010.06.07 10:07:47 LOG5[2768:560]: Service client connected remote server from 127.0.0.1:2085
    2010.06.07 10:07:47 LOG7[2768:560]: Remote FD=276 initialized
    2010.06.07 10:07:47 LOG7[2768:560]: Option TCP_NODELAY set on remote socket
    2010.06.07 10:07:47 LOG7[2768:560]: SSL state (connect): before/connect initialization
    2010.06.07 10:07:47 LOG7[2768:560]: SSL state (connect): SSLv3 write client hello A
    2010.06.07 10:07:47 LOG3[2768:560]: SSL_connect: Peer suddenly disconnected
    2010.06.07 10:07:47 LOG5[2768:560]: Connection reset: 0 bytes sent to SSL, 0 bytes sent to socket
    2010.06.07 10:07:47 LOG7[2768:560]: Service client finished (0 left)

    сбрасывается соединение, а в нормальном виде должно быть так:

    2010.06.07 10:09:11 LOG7[2768:604]: Service client accepted FD=268 from 127.0.0.1:2108
    2010.06.07 10:09:11 LOG7[2768:604]: Creating a new thread
    2010.06.07 10:09:11 LOG7[2768:604]: New thread created
    2010.06.07 10:09:11 LOG7[2768:1476]: Service client started
    2010.06.07 10:09:11 LOG7[2768:1476]: FD=268 in non-blocking mode
    2010.06.07 10:09:11 LOG7[2768:1476]: Option TCP_NODELAY set on local socket
    2010.06.07 10:09:11 LOG5[2768:1476]: Service client accepted connection from 127.0.0.1:2108
    2010.06.07 10:09:11 LOG7[2768:1476]: FD=280 in non-blocking mode
    2010.06.07 10:09:11 LOG6[2768:1476]: connect_blocking: connecting 194.143.138.138:2214
    2010.06.07 10:09:11 LOG7[2768:1476]: connect_blocking: s_poll_wait 194.143.138.138:2214: waiting 10 seconds
    2010.06.07 10:09:18 LOG5[2768:1476]: connect_blocking: connected 194.143.138.138:2214
    2010.06.07 10:09:18 LOG5[2768:1476]: Service client connected remote server from 127.0.0.1:2109
    2010.06.07 10:09:18 LOG7[2768:1476]: Remote FD=280 initialized
    2010.06.07 10:09:18 LOG7[2768:1476]: Option TCP_NODELAY set on remote socket
    2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): before/connect initialization
    2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 write client hello A
    2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 read server hello A
    2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 read server certificate A
    2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 read server done A
    2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 write client key exchange A
    2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 write change cipher spec A
    2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 write finished A
    2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 flush data
    2010.06.07 10:09:18 LOG7[2768:1476]: SSL state (connect): SSLv3 read finished A
    2010.06.07 10:09:18 LOG7[2768:1476]:    1 items in the session cache
    2010.06.07 10:09:18 LOG7[2768:1476]:    2 client connects (SSL_connect())
    2010.06.07 10:09:18 LOG7[2768:1476]:    1 client connects that finished
    2010.06.07 10:09:18 LOG7[2768:1476]:    0 client renegotiations requested
    2010.06.07 10:09:18 LOG7[2768:1476]:    0 server connects (SSL_accept())
    2010.06.07 10:09:18 LOG7[2768:1476]:    0 server connects that finished
    2010.06.07 10:09:18 LOG7[2768:1476]:    0 server renegotiations requested
    2010.06.07 10:09:18 LOG7[2768:1476]:    0 session cache hits
    2010.06.07 10:09:18 LOG7[2768:1476]:    0 external session cache hits
    2010.06.07 10:09:18 LOG7[2768:1476]:    0 session cache misses
    2010.06.07 10:09:18 LOG7[2768:1476]:    0 session cache timeouts
    2010.06.07 10:09:18 LOG6[2768:1476]: SSL connected: new session negotiated
    2010.06.07 10:09:18 LOG6[2768:1476]: Negotiated ciphers: AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1
    2010.06.07 10:09:19 LOG7[2768:1476]: Socket closed on read
    2010.06.07 10:09:19 LOG7[2768:1476]: SSL write shutdown
    2010.06.07 10:09:19 LOG7[2768:1476]: SSL alert (write): warning: close notify
    2010.06.07 10:09:19 LOG6[2768:1476]: SSL_shutdown successfully sent close_notify
    2010.06.07 10:09:19 LOG7[2768:1476]: SSL alert (read): warning: close notify
    2010.06.07 10:09:19 LOG7[2768:1476]: SSL closed on SSL_read
    2010.06.07 10:09:19 LOG7[2768:1476]: Socket write shutdown
    2010.06.07 10:09:19 LOG5[2768:1476]: Connection closed: 36 bytes sent to SSL, 937 bytes sent to socket



  • Ну тогда нужно читать про этот туннельв мануалах - не пытается ли сервер Банка установить обратный коннект? Это также можно посмотреть в стейтах (states). Если что - можно будет попробовать сделать его мапингом.

    Также смотрите - в pfsense есть тоже пакет stunnel. Может поиграть с ним (если эта таже программа)?



  • Интересно откуда block out появляется.
    Глянь /tmp/rules.debug
    Найди там это правило (с block out on xl0) и что там в округе этого правило? какие-нибудь комменты?



  • Торможу чего-то - 'block out on xl0:' ясно говорит что исходящий пакет c WAN не пропускается. Там-же NAT от имени WAN все отправляет. Нужно правило 'разрешить tcp/udp с WAN интерфейса в любую сторону'.



  • @dvserg:

    Торможу чего-то - 'block out on xl0:' ясно говорит что исходящий пакет c WAN не пропускается.
    Нужно правило 'разрешить tcp/udp с WAN интерфейса в любую сторону'.

    Через гуи сделать out невозможно, можно только in.



  • @Evgeny:

    @dvserg:

    Торможу чего-то - 'block out on xl0:' ясно говорит что исходящий пакет c WAN не пропускается.
    Нужно правило 'разрешить tcp/udp с WAN интерфейса в любую сторону'.

    Через гуи сделать out невозможно, можно только in.

    Значит во-истину торможу  ???



  • @dvserg:

    @Evgeny:

    @dvserg:

    Торможу чего-то - 'block out on xl0:' ясно говорит что исходящий пакет c WAN не пропускается.
    Нужно правило 'разрешить tcp/udp с WAN интерфейса в любую сторону'.

    Через гуи сделать out невозможно, можно только in.

    Значит во-истину торможу  ???

    Похоже выходные удались! ;-)))



  • Похоже выходные удались! ;-)))

    Нуууу есть немного..  ;)



  • Я посмотрел /tmp/rules.debug и ничего там криминального не нашел, в частности указаний на block out on xl0. Там всего две строки содержащие "block out"

    Block all IPv6

    block in quick inet6 all
    block out quick inet6 all
    #–-------------------------------------------------------------------------

    default deny rules

    #---------------------------------------------------------------------------
    block in log quick all label "Default deny rule"
    block out log quick all label "Default deny rule"

    что мне лично кажется совсем не тем, что может мешать :)



  • Странно… У тебя ж в логе говорится "правило номер 102"
    погляди pfctl -sr -vv
    что там в сто втором правиле?



  • @Evgeny:

    Странно… У тебя ж в логе говорится "правило номер 102"
    погляди pfctl -sr -vv
    что там в сто втором правиле?

    Да, команда показывает правило 102:

    [Inserted: uid 0 pid 50821]
    @102 block drop out log quick all label "Default deny rule"
    [Evaluations: 45     Packets: 45      Bytes: 1800      States: 0      ]

    я пробовал удалять дефолтное запрещающее все правило на WAN интерфейсе, и менял его на разрешающее, в итоге 102 правило удаляется и генирируется другое с таким же содержимым

    [Inserted: uid 0 pid 1400]
    @98 block drop out log quick all label "Default deny rule"
    [Evaluations: 2    Packets: 2      Bytes: 362      States: 0      ]

    и лог:

    Jun 10 09:16:49 pf: 1. 515161 rule 98/0(match): block out on xl0: (tos 0x0, ttl 127, id 31169, offset 0, flags [DF], proto TCP (6), length 181) 77.108.92.4.17532 > 194.143.138.138.2214: FP, cksum 0x89dd (correct), 2293132943:2293133084(141) ack 2406608847 win 65535



  • Так, стоп.  А что```
    pfctl -sr | grep xl0



  • кажет вот это:

    block drop in log quick on xl0 inet proto udp from any port = bootps to 10.6.0.0/24 port = bootpc label "block dhcp client out wan"
    block drop in on ! xl0 inet from 77.108.92.0/29 to any
    block drop in on xl0 inet6 from fe80::204:75ff:fec2:54f6 to any
    block drop in log quick on xl0 inet from 10.0.0.0/8 to any label "block private networks from wan block 10/8"
    block drop in log quick on xl0 inet from 127.0.0.0/8 to any label "block private networks from wan block 127/8"
    block drop in log quick on xl0 inet from 172.16.0.0/12 to any label "block private networks from wan block 172.16/12"
    block drop in log quick on xl0 inet from 192.168.0.0/16 to any label "block private networks from wan block 192.168/16"
    block drop in log quick on xl0 from <bogons>to any label "block bogon networks from wan"
    pass out quick on xl0 proto icmp all keep state label "let out anything from firewall host itself"
    pass out quick on xl0 all flags S/SA keep state (tcp.closed 5) label "let out anything from firewall host itself"
    pass out quick on xl0 all flags S/SA keep state label "let out anything from firewall host itself"
    pass in quick on xl0 reply-to (xl0 77.108.92.1) inet proto tcp from any to 10.6.0.61 port = smtp flags S/SA keep state label "USER_RULE: NAT SMTP (internet) -> SMTP (local: 10.6.0.61)"
    block drop in quick on xl0 reply-to (xl0 77.108.92.1) inet all label "USER_RULE: block all"
    pass in quick on xl0 inet proto tcp from any port = ftp-data to (xl0) port > 49000 flags S/SA keep state label "FTP PROXY: PASV mode data connection"</bogons>



  • Похоже клиент или сервер закрывает tcp-connection.
    Давай смотреть более детально

    tcpdump -ni xl0 host 194.143.138.138
    

    На сколько я понимяю 194.143.138.138 - это удалённая сторона.



  • @Evgeny:

    Похоже клиент или сервер закрывает tcp-connection.
    Давай смотреть более детально

    tcpdump -ni xl0 host 194.143.138.138
    

    На сколько я понимяю 194.143.138.138 - это удалённая сторона.

    да! я сам только сегодня дошел до звонка в тех. поддержку банка, где мне сказали что связь с ними возможна только с IP указанного в заявке на подключение, и чтобы его сменить нужно подавать еще какую-то заявку  :) В общем поменял WAN адрес на нужный и все заработало. Извиняюсь за отнятое время, и спасибо за помощь)



  • @ASCII:

    @Evgeny:

    Похоже клиент или сервер закрывает tcp-connection.
    Давай смотреть более детально

    tcpdump -ni xl0 host 194.143.138.138
    

    На сколько я понимяю 194.143.138.138 - это удалённая сторона.

    да! я сам только сегодня дошел до звонка в тех. поддержку банка, где мне сказали что связь с ними возможна только с IP указанного в заявке на подключение, и чтобы его сменить нужно подавать еще какую-то заявку  :) В общем поменял WAN адрес на нужный и все заработало. Извиняюсь за отнятое время, и спасибо за помощь)

    Ничего, бывает. Хорошо, что заработало, а то Банк всё-таки ;-)


Locked