Hello, Hello!
Today I want to share with you one very unpleasant observation on the work of MS SQL Server 2000.
I work in a company that still uses MS SQL Server 2000 in its branches. I don’t know what goals they are pursuing with this, but this is not important, since the system is stable and the goals and tasks are fulfilled.
')
Let's start in order. I ask under habrakat.
Objectives of the solution
MS SQL Server 2000 performs the role of a database server, collecting and storing information and sharing it with Moscow and our subordinate representative offices, which are located at a distance of 100 km or more from our branch. We ourselves are at a distance of more than 2500 km from Moscow. This is so for the big picture.
When appearing in our branch office, as well as in the subordinate representative offices of normal and stable access to the Internet, it was decided to tie up with sending files by mail for data exchange. To this end, it was decided to connect at that time two ADSL modems for me and at the representative office through the DynDNS service for data exchange.
No sooner said than done
We register two free accounts on DynDNS.org, we get a host, register in modems in the DDNS section, set up virtual servers in modems and forward to port 3389 (RDP), for more convenient operation. With this, when connecting to a remote host, via Linux rdesktop, I received the connected disk of my Linux machine and quietly exchanged files.
Files are Access databases, which are formed on a remote MS SQL Server 2000, and by means of programs written by Moscow, uploaded to my MS SQL Server 2000.
After such not tricky manipulations, the work went faster, but did not suit one, every day began with one thing:
Morning, I came to work formed a file at myself, connected, formed a file on a remote server, transferred my file to a remote one, transferred it from a remote file to my own, uploaded them with special programs on MS SQL Server. Tired out.
It was decided to combine two MS SQL Servers using DynDNS with port forwarding in TCP modems 1433-1434 and UDP 1433-1434.
No sooner said than done
We go into the ADSL modem in the virtual servers section, forwarding TCP TCP ports. Connect special programs to a remote server and exchange data:
MS SQL Server Branch <-> MS SQL Server Representation. Hurray would say everything, so I said, but in the morning the most terrible and incomprehensible happened. Intrigue?
The next morning, after the automatic exchange of data between the SQL servers was set up at night, I received two dead MS Windows 2003. What do you mean dead:
- My MS Windows 2003 on which the Filial SQL server stood, fell off the domain on the network, did not let the network go to the ball and after reboot did not connect to the domain.
- remote MS Windows 2003 on which the SQL Server of the representative office stood, although it somehow responded to the connections, but behaved extremely inadequately, it would not allow to connect via RDP, then IIS fell, which was simply necessary in the representative office.
The blessing in the branch for such cases lay the backup of your MS Windows 2003, and the SQL databases were backed up on the SLES server. The work of the branch server was restored in a short period of time. Remote remind 100 km. go, was tested for viruses that have not been identified! After checking the server manually, what is wrong with it, it was found that the owner of the C: drive changed on the server and the remaining drives were undefined. For the sake of interest, I tried to return it on all the disks of the owner, the Administrator. After several hours of changing attributes, the server began to work normally. With peace of mind, I checked the exchange and info in the databases, everything was in place.
The next morning. The same picture !!! Horror.
I decided to try the owner recovery method on the Filial server because the owner was not defined. Restored at home, Restored at the remote all earned. And then the question arose because of what is happening. The answer was found the next morning, when, before this, I also remotely removed the forwarding of SQL Server ports, and remind TCP UDP 1433-1434. In the morning the server worked without errors.
Bug Breaking into? Vulnerability? What? It tormented me for a long time while I was transferring files between computers in the old way. Finally, a fiber optic Internet with white IP appeared in the branch. Well, now I think everything will be fine. Although the representative office still had a dynamic IP with a transfer to 3389 (RDP).
Solution of the problem of combining SQL servers using OpenSUSE, DynDNS
The task remained the same, to combine two SQL servers.
No sooner said than done
At first there was a simple goal, through OpenSUSE performing the role of a Router to push the port to the SQL server of the network in the firewall, we write
FW_FORWARD_MASQ = "0/0, ip_sql_server, tcp, 1433.1434, our_white_IP 0/0, ip_sql_server, udp, 1433.1434, our_white_IP"
Opening ports 1433-1434
This means that the traffic going to the machine with white ip on ports 1433 1434 is redirected to the machine with the SQL server of the internal network.
From a remote computer we try to connect to the SQL of our network, the connection was successful. Hooray! But one thing remains, as my SQL server to connect to a remote server. I make the decision to forward the SQL port on the ADSL modem of the remote computer. And by means of DynDNS connect from yourself to it. Forward, connect, share data. Well, we are waiting for the morning.
Morning. Nde This time is not so bad!
1. on my server in the root of the C drive: the files are:
xp5.exe
server.exe
hex.exe
and a bunch of incomprehensible dll'ok
Someone was on the server! :) Also, tasks like a.exe server.exe appeared in the job server SQL server and so on, and what is interesting is not to be determined by all antivirus.
2. the same story on a remote server.
But besides, the ADSL modem is hanging, I cannot remove the forwarding.
Simple manual cleaning, deleting these files, killing processes, cleaning the SQL job.
Connect via telnet, reset the modem completely.
Reboot
In general, the solution to this problem was always in plain sight.
Climax
We are raising to openSUSE vpn server pptpd (did not bother with openvpn) in the firewall we write:
FW_FORWARD = ”net_vpn, ip_server_sql_local ip_server_sql_local, net_vpn”
The remote server connects to the vpn server, gets an IP and only sees the sql server on my network. The exchange is normal and calm MORNING.
That's all. Works like a clock.
Shl. I wrote on my own, without going into details of the settings, if that is not what I suffer in the comments.