![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Наткнулись на проблему у клиентов - прога не хочет подключатся к Firebird через VPN, хоть ты тресни.
В процессе разборок, сопровождаемых отпаданием удаленного коннекта к клиентам каждые 5 минут, свели проблему к тому, что модем, посредством которого клиенты подключены к VPN, не отвечает на пакеты с флагом Don`t fragment правильным ICMP ответом "fragmentation needed". А у Firebird мало того что пакеты размером с весь MTU виндов, так еще и флаг этот установлен. Поэтому коннект на первом же длинном пакете затыкается напрочь, бессимптомно - сервер ждет запроса, клиент ждет потерянного ответа от сервера.
Придется завтра пытаться применить виндо-костылики отсюда: http://technet.microsoft.com/en-us/library/cc958871.aspx что усугубляется сидением юзеров на системе, которую придется перенастраивать.
PS: Итого, виндо-костылик сработал.
Сначала мы попробовали в Firebird поставить TcpRemoteBufferSize в 1448 (нижний предел для этого параметра, почему он такой - не помнят даже разработчики). Сначала Firebird это помогло, потом опять перестало подключатся. Почему - черт его знает, разбираться по тормозящему каналу влом.
Потом поставили виндокостылик в виде:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnablePMTUBHDetect"=dword:00000001
"EnablePMTUDiscovery"=dword:00000000
На самом деле, нужен только один из этих параметров, и кажется мне, что нужен второй - потому что первый будет тупить при попытке обнаружить и обойти Black Hole.
Комп потребовалось перегрузить, после чего все таки заработало.
Если по хорошему, то надо было бы ехать туда с запасным ADSL модемом, ноутом, подключатся в их сеть и сидеть со снифером смотреть, куда пропадают долбаные ICMP ответы. Но мне это делать запрещено начальством, а так же меня за подобные развлечения ненавидят воображаемые канадские линуксоиды, которые почему-то никогда не сталкивались с такими проблемами.
В процессе разборок, сопровождаемых отпаданием удаленного коннекта к клиентам каждые 5 минут, свели проблему к тому, что модем, посредством которого клиенты подключены к VPN, не отвечает на пакеты с флагом Don`t fragment правильным ICMP ответом "fragmentation needed". А у Firebird мало того что пакеты размером с весь MTU виндов, так еще и флаг этот установлен. Поэтому коннект на первом же длинном пакете затыкается напрочь, бессимптомно - сервер ждет запроса, клиент ждет потерянного ответа от сервера.
Придется завтра пытаться применить виндо-костылики отсюда: http://technet.microsoft.com/en-us/library/cc958871.aspx что усугубляется сидением юзеров на системе, которую придется перенастраивать.
PS: Итого, виндо-костылик сработал.
Сначала мы попробовали в Firebird поставить TcpRemoteBufferSize в 1448 (нижний предел для этого параметра, почему он такой - не помнят даже разработчики). Сначала Firebird это помогло, потом опять перестало подключатся. Почему - черт его знает, разбираться по тормозящему каналу влом.
Потом поставили виндокостылик в виде:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters]
"EnablePMTUBHDetect"=dword:00000001
"EnablePMTUDiscovery"=dword:00000000
На самом деле, нужен только один из этих параметров, и кажется мне, что нужен второй - потому что первый будет тупить при попытке обнаружить и обойти Black Hole.
Комп потребовалось перегрузить, после чего все таки заработало.
Если по хорошему, то надо было бы ехать туда с запасным ADSL модемом, ноутом, подключатся в их сеть и сидеть со снифером смотреть, куда пропадают долбаные ICMP ответы. Но мне это делать запрещено начальством, а так же меня за подобные развлечения ненавидят воображаемые канадские линуксоиды, которые почему-то никогда не сталкивались с такими проблемами.
