exo Posted July 17, 2013 Share Posted July 17, 2013 Здравейте, не знам дали темата е точно за този раздел, но след прочитане сами ще прецените. Наскоро ми се наложи да направя замяна на един сървър, използван главно за openvpn tunneling и работещ като рутер. Старата машина бе базирана на Fedora 8. Смених я със съвсем различна машина базирана на CentOS 6.4. Пренесох конфигурацията от едната машина на другата (за iptables, openvpn и т.н.), всичко си тръгна както трябва, с едно изключение, но за това след малко. Към този openvpn сървър има свързани клиенти, които вървят на tomatousb с openvpn мод и на клиентския рутер се извършва маскиране на клиентската подмрежа спрямо openvpn-ската с iptables. Във vpn-ската мрежа има един windows server 2008, към който клиентите от техните си подмрежи се свързват посредством описания по назад setup. Всичко това работеше без проблеми на fedora-та, но на CentOS се появи много странен проблем, който се проявява само на този wdinwso server 2008. Проблема е че от и към win сървъра не минава нищо свързано с тези клиенти, които се опитват да се свържат през vpn тунела към него, от техните си подмрежи. Има други клиенти свързани към vpn тунела, само че от компютри, не от tomatousb рутети с които всичко е наред, свръзват си се към win сървъра и нямат проблем. Още по интересната част е че след пускане на трафик снифър (wireshark в случая), според него към и от проблемните клиенти, които са с tomatousb рутерите, минава ping, въпреки че на екрана на win сървъра същия този пинг излиза като timed out. Този проблем се наблюдава само с въпросния win сървър, другите машини в openvpn-ската мрежа нямат този проблем, към тях клиентите зад tomato рутерите имат връзка и обратно - те също имат връзка към тези рутери. Проверил съм по няколко пъти всичко: конфигурацията на openvpn, iptables, рутинг таблици, arp, дори си играх с mtu-тата - всичко изглежда вярно, поне на теория, но на практика не, поне за Mr. windows server 2008 Моля ако някой разбра нещо нека да помогне Link to comment Share on other sites More sharing options...
ARPAnet Posted July 17, 2013 Share Posted July 17, 2013 Сравни рутинг таблицата на уин машината с тази на друга машина стояща от същата страна на впн-а. Уин сървъра и околните машини в един и същи събнет ли са ? Ако Уин сървъра е в същият събнет като околните машини, то със сигурност проблема е в самият уин сървъра, защото за него важат същите правила като за останалите. Link to comment Share on other sites More sharing options...
exo Posted July 17, 2013 Author Share Posted July 17, 2013 Сравни рутинг таблицата на уин машината с тази на друга машина стояща от същата страна на впн-а. Уин сървъра и околните машини в един и същи събнет ли са ? Ако Уин сървъра е в същият събнет като околните машини, то със сигурност проблема е в самият уин сървъра, защото за него важат същите правила като за останалите. Еднакви са рутинг таблиците. Уин сървъра е в същия събнет като околните и ... май проблема е в него наистина ... обаче къде и защо? Link to comment Share on other sites More sharing options...
ARPAnet Posted July 17, 2013 Share Posted July 17, 2013 Firewall? Виж в каква мрежа се води според network and sharing center-а. Да не е някакъв private/domain only Някакви специфични правила за този сървър в iptables на впн сървъра ? Link to comment Share on other sites More sharing options...
exo Posted July 17, 2013 Author Share Posted July 17, 2013 Firewall? Виж в каква мрежа се води според network and sharing center-а. Да не е някакъв private/domain only Някакви специфични правила за този сървър в iptables на впн сървъра ? Ами той самия е домейн контролер, мрежата се води "Domain Network" в Network and sharing center-а. Firewall има вдигнат, но нищо не е пипано нито по него, нито по машината изобщо, сега го прегледах пак - нищо нередено няма във firewall-а, но съм пробвал и със свален такъв - без резултат. Не знам дали е от значение, не съм споменал че е windows server 2008 SP2 (не R2). В същия събнет има още два windows server-а 2008, те са R2 и при тях го няма този проблем, нямат специални функций, като домейн контролер. Сравних им пак рутинг таблиците - еднакви в IPv4 частта, като изключим различните IP адреси. Специфични правила в iptables ... има само един port forwarding, за един tcp port от проблемната машина към интернет, но iptables-а го пробвах с най-различни варианти и не е това проблема. Всъщност има една разлика в самия iptables между стария vpn сървър и новия, но не мисля че е от значение: Разликата е че от netfilter са направили промяна и nat веригата не приема за таргет -j DROP и -j REJECT. Приема само ACCEPT и съответно DNAT и SNAT. Презумцията била че така нямало да се бърка предназначението на нат веригата с тази на филтър ... Link to comment Share on other sites More sharing options...
ARPAnet Posted July 17, 2013 Share Posted July 17, 2013 Евентуално клиентите зад томатотата да имат някакъв специфичен рутинг към този домейн контролер, и след промяната да си сменил някое ип ? А самият впн сървър вижда ли домейн контролера, пинг и т.н. ? Може да пробваш и от томатотата да го пингнеш, поне да се види къде се губи връзката. Link to comment Share on other sites More sharing options...
exo Posted July 17, 2013 Author Share Posted July 17, 2013 Евентуално клиентите зад томатотата да имат някакъв специфичен рутинг към този домейн контролер, и след промяната да си сменил някое ип ? А самият впн сървър вижда ли домейн контролера, пинг и т.н. ? Може да пробваш и от томатотата да го пингнеш, поне да се види къде се губи връзката. IP-та не съм променял. Клиентите зад томатотата не ползват сървъра като домейн контролер, а като база данни (MS SQL), така че само маскиране им върши работа и няма настроен специфичен рутинг при тях. Самия VPN вижда ясно и пингва уин сървъра. Това с пинга от томатотата съм го пробвал и от двете страни (и от тях към уин сървъра, и обратно), на екрана излиза request timed out, но според wireshark пинг има, вървят си последователно Echo (ping) request и Echo (ping) reply със същия source и destination, каквито се очаква. Link to comment Share on other sites More sharing options...
exabyte Posted July 17, 2013 Share Posted July 17, 2013 Ако shark-а казва, че има връзка, какво връща telnet от клиентите до SQL сървъра на порт 1433 или който там си задал? Windows-a с SP2 има ли NPS? Link to comment Share on other sites More sharing options...
exo Posted July 18, 2013 Author Share Posted July 18, 2013 Ако shark-а казва, че има връзка, какво връща telnet от клиентите до SQL сървъра на порт 1433 или който там си задал? Windows-a с SP2 има ли NPS? telnet казва: Could not open connection to the host, on port 1433: Connect failed При wireshark излиза това: NPS Има, но не мисля че изобщо е настройван и като гледам така си е с default settings. Link to comment Share on other sites More sharing options...
exo Posted July 20, 2013 Author Share Posted July 20, 2013 Така. Проблемния уин сървър не е update-ван от както му е инсталиран SP2, до момента имаше не инсталирани общо 58 update-а. Най-накрая се споразумях с хората които релано експлатират тази машина да му инсталираме всичките чакащи до момента update-и, казвам, споразумях защото от една седмица ми се разтягаха едни теории от тях как това щяло да им "омаже" някои много важни настройки. Е настройки не се омазаха след като инсталирах всичките update-и, но за сметка на това супер странния проблем изчезна както се беше появил. Не знам коя от 58-те кръпки на M$ реши проблема, но факт е че сега всичко е наред. Тепърва ще ровя в лога и KB-то на М$ да видя какво толкова закърпиха че да се случват такива тъпи ситуации. Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.