本日は、MS SQL Server 2000の動作に関する非常に不愉快な見解を皆さんと共有したいと思います。
私はまだ支社でMS SQL Server 2000を使用している会社に勤めています。彼らがどのような目標を追求しているかはわかりませんが、システムは安定して機能し、目標と目標を達成するため、これは重要ではありません。
順番に始めましょう。 habrakatをお願いします。
ソリューション目標の目的
MS SQL Server 2000はデータベースサーバーとして機能し、情報を収集して保存し、モスクワと支社から100 km以上離れた支社と情報を交換しますが、私たち自身はモスクワから2500 km離れた距離にあります。これは全体像にとってはそうです。
通常の安定したインターネットアクセスが支社と下位のミッションに登場したとき、データ交換のためにメールでファイルを接続することが決定されました。 このため、その時点で、私のオフィスにある2つのADSLモデムとデータ交換用のDynDNSサービスを介して接続することが決定されました。
すぐに言われた
より便利な操作のために、DynDNS.orgに2つの無料アカウントを登録し、ホストを取得し、DDNSセクションのモデムに登録し、モデムの仮想サーバーを構成して、ポート3389（RDP）に転送します。 これで、Linux経由でリモートホストに接続するときに、rdesktopはLinuxマシンのマップされたドライブを受け取り、静かにファイルを交換しました。
ファイルはAccessデータベースであり、リモートのMS SQL Server 2000で生成され、モスクワが作成したプログラムを介してMS SQL Server 2000にアップロードされます。
このようなトリッキーな操作の後、作業は速くなりましたが、1つのことは好きではありませんでした。
朝、仕事に来て、自分の場所でファイルを作成し、接続し、リモートサーバーにファイルを作成し、ファイルをリモートサーバーに転送し、リモートファイルから自分のファイルに転送し、特別なプログラムをMS SQL Serverにアップロードしました。 疲れた。
TCP 1433-1434およびUDP 1433-1434モデムのポート転送でDynDNSを使用して、2つのMS SQL Serverを組み合わせることが決定されました。
終わった
仮想サーバーセクションのADSLモデムに入り、TCP UDPポートを転送します。 特別なプログラムをリモートサーバーに接続し、データを交換します。
MS SQL Serverブランチオフィス<-> MS SQL Server表現。 ウルは私が言ったようにすべてを言うだろうが、午前中に最も恐ろしく、理解できないことが起こった。 陰謀？
翌朝、SQLサーバー間で夜間のデータの自動交換が設定された後、2つの死んだMS Windows 2003を受け取りました。死の意味は次のとおりです。
- ブランチSQLサーバーが存在する私のMS Windows 2003は、ネットワーク上のドメインから落ち、ネットワーク経由でボールを放り出せず、再起動後にドメインに接続しませんでした。
- 駐在員事務所のSQLサーバーが立っていたリモートMS Windows2003。接続に何らかの形で応答しましたが、非常に不適切に動作し、RDP経由で接続できなかったため、駐在員事務所で単に必要でした。
幸いなことに、MS Windows 2003のバックアップはこのような場合のブランチにあり、SQLデータベースはSLESサーバーにバックアップされました。 ブランチサーバーの作業は短時間で復元されました。 リモートに100 kmを思い出させます。 検出されなかったウイルスをチェックしました！ サーバーの問題を手動で確認した後、C：ドライブの所有者と無期限のドライブの残りのドライブがサーバー上で変更されていることがわかりました。 興味のために、私はすべてのディスクの管理者、管理者を返そうとしました。 属性を数時間変更した後、サーバーは正常に動作し始めました。 落ち着いて、私はデータベースの交換と情報をチェックしました。すべてが整っていました。
翌朝。 同じ絵!!! ホラー
所有者が定義されていないため、ブランチサーバーで所有者を復元する方法を試すことにしました。 自宅で復元し、すべてが機能したリモートに復元しました。 そして、これが何が起こっているのかという疑問が生じました。 答えは翌朝に見つかりました。その前に、SQL Serverポートのポートフォワーディングをリモートで自分から削除したときに、TCP UDP 1433-1434を思い出します。 朝、サーバーはエラーなく動作しました。
バグ？ ハッキング？ 脆弱性？ なに？ 古い方法でコンピューター間でファイルを転送している間、それは長い間私を苦しめました。 そして最後に、白いIPを備えた光ファイバーインターネットが支店に登場しました。 さて、私はすべてがうまくいくと思います。 駐在員事務所は3389（RDP）に転送する動的IPのままでしたが。
OpenSUSE、DynDNSを使用してSQLサーバーを結合する問題を解決する
タスクは同じままで、2つのSQLサーバーを結合します。
終わった
最初に、ルーターとして機能するOpenSUSEを通じて、ファイアウォール内のSQLネットワークサーバーにポートを転送するという簡単な目標がありました。
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"
ポート1433-1434を開きます
これは、ポート1433 1434に白いipを持つマシンに向かうトラフィックが、内部ネットワーク上のSQLサーバーからマシンにリダイレクトされることを意味します。
リモートコンピューターから、ネットワークのSQLに接続しようとしていますが、接続は成功しました。 やった！ ただし、SQLサーバーをリモートサーバーに接続する方法は1つ残っています。 SQLポートをリモートコンピューターのADSLモデムに転送することにします。 そして、DynDNSを使用して、自分から接続します。 データを転送、接続、交換します。 さて、朝を待ちます。
朝 んで。 今回はそれほど悪くない！
1. C：ドライブのルートにあるサーバー上のファイルは次のとおりです。
xp5.exe
server.exe
hex.exe
そして奇妙なdll'okの束
誰かがサーバーにいました！ :)また、a.exe server.exeなどのタスクはジョブSQLサーバーなどに登場しました。すべてがウイルス対策として検出されないのは興味深いことです。
2.リモートサーバー上の同じストーリー。
しかし、ADSLモデムもハングしているため、プロブロを削除することはできません。
簡単な手動クリーニング、これらのファイルの削除、プロセスの強制終了、SQLジョブのクリーニング。
telnet経由で接続し、モデムを完全にリセットします。
再起動
一般に、この問題の解決策は常に見えていました。
クライマックス
OpenSUSE vpnサーバーpptpd（openvpnに煩わされなかった）で、私たちが書いたファイアウォールでレイズします：
FW_FORWARD =” net_vpn、ip_server_sql_local ip_server_sql_local、net_vpn”
リモートサーバーはvpnサーバーに接続し、IPを受信します。ネットワークでは、sqlサーバーのみが表示されます。 朝の交換は普通で穏やかです。
それだけです。 時計のように機能します。
脅威。 コメントに間違いがある場合は、設定の詳細に入らずに自分で書きました。