Jump to content
BulForum.com

CentOS 6.4, OpenVPN 2.3 и Windows Server 2008 - много интересен пробле


exo

Recommended Posts

Здравейте,

не знам дали темата е точно за този раздел, но след прочитане сами ще прецените.

Наскоро ми се наложи да направя замяна на един сървър, използван главно за 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 :)

 

Моля ако някой разбра нещо нека да помогне :grin:

Link to comment
Share on other sites

Сравни рутинг таблицата на уин машината с тази на друга машина стояща от същата страна на впн-а.  Уин сървъра и околните машини в един и същи събнет ли са  ?

Ако Уин сървъра е в същият събнет като околните машини, то със сигурност проблема е в самият уин сървъра, защото за него важат същите правила като за останалите. :)

Link to comment
Share on other sites

Сравни рутинг таблицата на уин машината с тази на друга машина стояща от същата страна на впн-а.  Уин сървъра и околните машини в един и същи събнет ли са  ?

Ако Уин сървъра е в същият събнет като околните машини, то със сигурност проблема е в самият уин сървъра, защото за него важат същите правила като за останалите. :)

Еднакви са рутинг таблиците. Уин сървъра е в същия събнет като околните и ... май проблема е в него наистина ... обаче къде :confused и защо?

Link to comment
Share on other sites

Firewall? Виж в каква мрежа се води според network and sharing center-а. Да не е някакъв private/domain only

Някакви специфични правила за този сървър в iptables на впн сървъра ?

Link to comment
Share on other sites

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

Евентуално клиентите зад томатотата да имат някакъв специфичен рутинг към този домейн контролер, и след промяната да си сменил някое ип ?

А самият впн сървър вижда ли домейн контролера, пинг и т.н. ? Може да пробваш и от томатотата да го пингнеш, поне да се види къде се губи връзката.

Link to comment
Share on other sites

Евентуално клиентите зад томатотата да имат някакъв специфичен рутинг към този домейн контролер, и след промяната да си сменил някое ип ?

А самият впн сървър вижда ли домейн контролера, пинг и т.н. ? Може да пробваш и от томатотата да го пингнеш, поне да се види къде се губи връзката.

IP-та не съм променял. Клиентите зад томатотата не ползват сървъра като домейн контролер, а като база данни (MS SQL), така че само маскиране им върши работа и няма настроен специфичен рутинг при тях. Самия VPN вижда ясно и пингва уин сървъра. Това с пинга от томатотата съм го пробвал и от двете страни (и от тях към уин сървъра, и обратно), на екрана излиза request timed out, но според wireshark пинг има, вървят си последователно Echo (ping) request и Echo (ping) reply със същия source и destination, каквито се очаква.

Link to comment
Share on other sites

Ако shark-а казва, че има връзка, какво връща telnet от клиентите до SQL сървъра на порт 1433 или който там си задал?

Windows-a с SP2 има ли NPS?

Link to comment
Share on other sites

Ако shark-а казва, че има връзка, какво връща telnet от клиентите до SQL сървъра на порт 1433 или който там си задал?

Windows-a с SP2 има ли NPS?

telnet казва:

Could not open connection to the host, on port 1433: Connect failed

При wireshark излиза това:

97c4c89954ee4425.jpg

NPS Има, но не мисля че изобщо е настройван и като гледам така си е с default settings.

Link to comment
Share on other sites

Така.

Проблемния уин сървър не е update-ван от както му е инсталиран SP2, до момента имаше не инсталирани общо 58 update-а. Най-накрая се споразумях с хората които релано експлатират тази машина да му инсталираме всичките чакащи до момента update-и, казвам, споразумях защото от една седмица ми се разтягаха едни теории от тях как това щяло да им "омаже" някои много важни настройки. Е настройки не се омазаха след като инсталирах всичките update-и, но за сметка на това супер странния проблем изчезна както се беше появил. Не знам коя от 58-те кръпки на M$ реши проблема, но факт е че сега всичко е наред. Тепърва ще ровя в лога и KB-то на М$ да видя какво толкова закърпиха че да се случват такива тъпи ситуации.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...