Nodejs がイントラネット侵入サービスを実装

1. LAN内のプロキシ

まず前回の記事を見直してみましょう。ローカルエリアネットワーク内でサービスプロキシを実装するにはどうすればよいでしょうか。これは非常に単純なので、すぐにコードを見てみましょう。

定数net = require('net')

const proxy = net.createServer(socket => {
  const localServe = 新しい net.Socket()
  localServe.connect(5502, '192.168.31.130') // LAN 内のサービス ポートと IP。

  socket.pipe(localServe).pipe(ソケット)
})

プロキシ.listen(80)

これは非常にシンプルなサーバー側プロキシです。コードはシンプルで明確です。質問がある場合は、おそらくここのパイプです。簡単に説明しましょう。ソケットは全二重ストリーム、つまり読み取りと書き込みの両方が可能なデータストリームです。コードでは、ソケットがクライアントからデータを受信すると、そのデータを localSever に書き込みます。localSever にデータがある場合、そのデータがソケットに書き込まれ、ソケットはそのデータをクライアントに送信します。

2. イントラネットの浸透

LAN プロキシは簡単ですが、イントラネットへの侵入はそれほど簡単ではありません。ただし、これはコアコードであり、かなりの論理処理が必要です。具体的に実装する前に、まずイントラネットの浸透度を整理しましょう。

イントラネット侵入とは何ですか?

簡単に言えば、ローカルエリアネットワーク内のサービスにアクセスできるパブリックネットワーククライアントです。たとえば、サービスはローカルで開始されました。パブリックネットワーククライアントは、ローカルで開始されたサーバーをどのようにして認識するのでしょうか?ここでは、パブリックネットワークサーバーに依存する必要があります。では、パブリックネットワークサーバーはどのようにしてローカルサービスを認識するのでしょうか?これには、ローカルとサーバー間のソケットリンクを確立する必要があります。

4つの役割

上記の説明を通じて、4つの役割を紹介します。

パブリックネットワーククライアントを client と名付けます。
パブリックネットワークサーバーはプロキシとして機能するため、proxyServe という名前が付けられています。
localServe という名前のローカルサービス。
ローカルソケットは、サーバーに長く接続されています。これは proxyServe と localServe の間のブリッジであり、データ転送を担当します。これをブリッジと名付けました。

このうち、クライアントと localServe については考慮する必要はありません。クライアントはブラウザなどであり、localServe は通常のローカルサービスにすぎないからです。注意する必要があるのは proxyServe と bridge だけです。ここで紹介するのは、やはり最もシンプルな実装方法であり、考え方や考え方を提供するものなので、まずは最もシンプルなものから始めましょう。

橋

4 つの役割のセクションから、ブリッジは proxyServe とのソケット接続であり、データの転送であることがわかります。コードを見て、アイデアを整理してみましょう。

定数net = require('net')

定数 proxyServe = '10.253.107.245'

const ブリッジ = 新しい net.Socket()
ブリッジ.connect(80, proxyServe, _ => {
  bridge.write('GET /regester?key=sq HTTP/1.1\r\n\r\n')
})

ブリッジ.on('データ', データ => {
  const localServer = 新しい net.Socket()
  localServer.connect(8088, 'localhost', _ => {
    localServer.write(データ)
    localServer.on('data', res => bridge.write(res))
  })
})

コードは明確で読みやすく、印象に残ります。ネットライブラリをインポートし、パブリックネットワークアドレスを宣言し、ブリッジを作成し、ブリッジを proxyServe に接続し、成功したら、ローカルサービスを proxyServe に登録します。次に、ブリッジはデータをリッスンし、リクエストが到着すると、ローカルサービスとの接続を作成します。成功したら、リクエストデータは localServe に送信され、同時にレスポンスデータがリッスンされ、レスポンスストリームがブリッジに書き込まれます。

残りについてはあまり説明する必要がありません。結局のところ、これは単なるサンプルコードです。ただし、サンプルコードには /regester?key=sq というセクションがあります。このキーは非常に便利です。ここでは key=sq です。次に、ロールクライアントがプロキシサービスを介してローカルサービスにアクセスするときに、proxyServe がブリッジに対応し、localServe に対応できるように、このキーをパスに追加する必要があります。

たとえば、lcoalServe は http://localhost:8088、rpoxyServe は example.com、登録キーは sq です。次に、prxoyServe を介して localServe にアクセスする場合は、次のように記述する必要があります: example.com/sq。なぜこのように書くのでしょうか?もちろん、これは単なる定義です。この記事のコードを理解したら、この規則を変更できます。

それでは、次のキーコードを見てみましょう。

プロキシサーブ

ここで紹介する proxyServe は簡略化されたサンプルコードではありますが、説明するのはまだ少し複雑です。十分に理解し、自分の業務と組み合わせて使えるコードにするには、ある程度の努力が必要です。ここではコードをいくつかの部分に分割して、わかりやすく説明します。説明を容易にするために、コードブロックに名前を付けます。
コードブロック 1: createServe

このブロックの主な機能は、プロキシサービスを作成し、クライアントとブリッジとのソケットリンクを確立し、ソケット上のデータ要求をリッスンし、コールバック関数で論理処理を実行することです。具体的なコードは次のとおりです。

定数net = require('net')

const bridges = {} // ブリッジがソケット接続を確立すると、ここにキャッシュされます。const clients = {} // クライアントがソケット接続を確立すると、ここにキャッシュされます。具体的なデータ構造については、ソースコードを参照してください。net.createServer(socket => {
  socket.on('data', データ => {
    const リクエスト = data.toString()
    const url = request.match(/.+ (?<url>.+) /)?.groups?.url
    
    if (!url) 戻り値

    if (isBridge(url)) {
      regesterBridge(ソケット、URL)
      戻る
    }

    const { ブリッジ、キー } = findBridge(リクエスト、URL)
    if (!bridge) 戻り値

    cacheClientRequest(ブリッジ、キー、ソケット、リクエスト、URL)

    キーによるブリッジへのリクエストの送信(キー)
  })
}).listen(80)

データモニターのコードロジックを見てみましょう。

リクエストデータを文字列に変換します。
リクエスト内の URL を探します。URL が見つからない場合は、リクエストを直接終了します。
URL を通じてブリッジかどうかを判断します。ブリッジである場合は、ブリッジを登録します。そうでない場合は、クライアント要求と見なします。
クライアント要求に登録済みのブリッジがあるかどうかを確認します。これはプロキシサービスであり、登録済みのブリッジがない場合、要求は無効とみなされることに注意してください。
このリクエストをキャッシュします。
次に、ブリッジにリクエストを送信します。

コードとロジックを組み合わせると、理解できるはずですが、5については疑問が残るかもしれません。1つずつ整理してみましょう。

コードブロック 2: isBridge

ブリッジ登録リクエストであるかどうかを判断する方法は非常に簡単ですが、実際のビジネスでは、より正確なデータが定義される場合があります。

関数isBridge(url){
  url.startsWith('/regester?') を返します
}

コードブロック 3: regesterBridge
簡単です。コードを見て説明してください:

関数regesterBridge（ソケット、URL）{
  定数キー = url.match(/(^|&|\?)key=(?<key>[^&]*)(&|$)/)?.groups?.key
  ブリッジ[キー] = ソケット
  socket.removeAllListeners('データ')
}

URL を通じて登録するブリッジのキーを見つけます。
ソケット接続をキャッシュします。
ブリッジのデータ監視を削除します - コードブロック 1 では、各ソケットにデフォルトのデータ監視コールバック関数があります。削除しないと、後続のデータが混乱します。

コードブロック 4: findBridge

ロジックがコードブロック 4 に到達すると、これはすでにクライアント要求であることを意味します。次に、まず対応するブリッジを見つける必要があります。ブリッジがない場合は、まずブリッジを登録する必要があり、その後、ユーザーはクライアント要求を開始する必要があります。コードは次のとおりです。

関数 findBridge (リクエスト、URL) {
  key = url.match(/\/(?<key>[^\/\?]*)(\/|\?|$)/)?.groups?.key とします。
  bridge = bridges[キー]とします
  if (bridge) return { bridge, key }

  const referer = request.match(/\r\nReferer: (?<referer>.+)\r\n/)?.groups?.referer
  if (!referer) が {} を返す

  キー = referer.split('//')[1].split('/')[1]
  bridge = 橋[キー]
  if (bridge) return { bridge, key }

  戻る {}
}

URL からプロキシするブリッジのキーを照合し、見つかった場合は対応するブリッジとキーを返します。
見つからない場合は、リクエストヘッダーのリファラーで検索します。見つかった場合は、ブリッジとキーが返されます。
いずれも見つかりません。このリクエストはコードブロック 1 で終了することが分かっています。

コードブロック 5: cacheClientRequest

ここでのコード実行は、それがすでにクライアントリクエストであることを示しています。まず、このリクエストをキャッシュします。キャッシュするときに、後続の操作を容易にするために、リクエストに対応するブリッジとキーバインディングもキャッシュします。

クライアント要求をキャッシュする理由は何ですか?

現在のソリューションでは、リクエストとレスポンスの両方がペアで順序付けられることを期待しています。ネットワーク伝送が断片化していることは周知の事実です。現状では、アプリケーション層でリクエストとレスポンスをペアにして順序付けて制御しないと、データパケット間の混乱が生じてしまいます。これが現状です。将来的にもっと良い解決策が見つかったら、アプリケーション層でデータの要求と応答を強制的に順序通りにするのではなく、TCP/IP 層を信頼することができます。
理由を説明した後、まずは比較的単純なキャッシュコードを見てみましょう。複雑なのは、リクエストを 1 つずつ取り出して、レスポンス全体を順番に返す点です。

関数cacheClientRequest(ブリッジ、キー、ソケット、リクエスト、URL){
  if (クライアント[キー]) {
    クライアント[キー].requests.push({ブリッジ、キー、ソケット、リクエスト、URL})
  } それ以外 {
    クライアント[キー] = {}
    クライアント[キー].requests = [{ブリッジ、キー、ソケット、リクエスト、URL}]
  }
}

まず、ブリッジに対応するキーの下にクライアント要求キャッシュがすでに存在するかどうかを判断します。存在する場合は、それをプッシュします。

そうでない場合は、オブジェクトを作成し、このリクエストを初期化します。

次のステップは最も複雑で、リクエストキャッシュを取り出してブリッジに送信し、現在の応答が終了するまでブリッジの応答をリッスンします。次に、ブリッジのデータ監視を削除し、次のリクエストを取り出すことを試み、クライアントからのすべてのリクエストが処理されるまで上記のアクションを繰り返します。

コードブロック 6: sendRequestToBridgeByKey

コードブロック 5 の最後に、ブロックの概要説明が示されます。まず少し理解してから次のコードを見てください。コードにはレスポンスの整合性の判断がいくつかあるからです。これらを削除すると、コードが理解しやすくなります。ソリューション全体では、リクエストの整合性は処理しませんでした。これは、ファイルアップロードインターフェイスでない限り、リクエストは基本的にデータパケットのサイズ内であるためです。ファイルアップロードインターフェイスは現時点では処理しません。そうでない場合、コードがより複雑になります。

関数 sendRequestToBridgeByKey (キー) {
  const client = クライアント[キー]
  if (client.isSending) 戻り値

  const リクエスト = client.requests
  if (requests.length <= 0) 戻り値

  client.isSending = true
  クライアント.コンテンツ長 = 0
  クライアント受信 = 0

  const {ブリッジ、ソケット、リクエスト、URL} = リクエスト.shift()

  const newUrl = url.replace(キー、'')
  const newRequest = request.replace(url, newUrl)

  bridge.write(新しいリクエスト)
  ブリッジ.on('データ', データ => {
    定数レスポンス = data.toString()

    code = response.match(/^HTTP[S]*\/[1-9].[0-9] (?<code>[0-9]{3}).*\r\n/)?.groups?.code とします。
    if (コード) {
      コード = parseInt(コード)
      (コード === 200) の場合 {
        contentLength = response.match(/\r\nContent-Length: (?<contentLength>.+)\r\n/)?.groups?.contentLength とします。
        if (コンテンツの長さ) {
          コンテンツの長さ = parseInt(コンテンツの長さ)
          client.contentLength = コンテンツの長さ
          client.received = Buffer.from(response.split('\r\n\r\n')[1]).length
        }
      } それ以外 {
        socket.write(データ)
        client.isSending = false
        bridge.removeAllListeners('データ')
        キーによるブリッジへのリクエストの送信(キー)
        戻る
      }
    } それ以外 {
      クライアントが受信したデータ += データの長さ
    }

    socket.write(データ)

    (client.contentLength <= client.received) の場合 {
      client.isSending = false
      bridge.removeAllListeners('データ')
      キーによるブリッジへのリクエストの送信(キー)
    }
  })
}

クライアントの中からブリッジキーに対応するクライアントを取り出します。
クライアントに送信中のリクエストがあるかどうかを判断します。ある場合は、実行を終了します。そうでない場合は、続行します。
クライアントの下にリクエストがあるかどうかを判断します。リクエストがある場合は続行し、ない場合は実行を終了します。
要求されたソケットとキャッシュされたブリッジを含むキューの最初のものを取得します。
合意したデータを置き換え、最終的な要求データをブリッジに送信します。
ブリッジからのデータ応答をリッスンします。

応答コードを取得する
- 応答が 200 の場合、そこからコンテンツの長さを取得します。取得できた場合は、このリクエストに対していくつかの初期化操作を実行します。リクエストの長さを設定します。送信されたリクエストの長さを設定します。
- 200でない場合は、データをクライアントに送信し、リクエストを終了し、データ監視を削除し、sendRequestToBridgeByKeyを再帰的に呼び出します。
コードが取得されない場合、この応答は最初のものではないと想定し、その長さが送信フィールドに追加されます。
その後、このデータをクライアントに送信します。
次に、応答の長さが送信されたデータの長さと一致しているかどうかを判断します。一致している場合は、クライアントのデータ送信ステータスを false に設定し、データ監視を削除して、sendRequestToBridgeByKey を再帰的に呼び出します。

この時点で、コアコードロジックは完成しました。

要約する

このコードセットを理解した後は、それを拡張して独自の用途に合わせてコードを充実させることができます。このコードセットを理解した後、他の使用シナリオを思いつくことができますか?このアイデアはリモートコントロールにも使用できますか? クライアントを制御したい場合は、このコードからインスピレーションを得ることができます。
このコードセットは難しいかもしれません。TCP/IP だけでなく、HTTP、いくつかの重要な要求ヘッダー、いくつかの重要な応答情報についてもすべて知っておく必要があるかもしれません。もちろん、HTTP について知っていることが増えれば増えるほど、より良くなります。
何かご連絡事項がございましたらメッセージを残してください。

proxyServe ソースコード

定数net = require('net')

const ブリッジ = {}
定数クライアント = {}

net.createServer(ソケット => {
  socket.on('data', データ => {
    const リクエスト = data.toString()
    const url = request.match(/.+ (?<url>.+) /)?.groups?.url
    
    if (!url) 戻り値

    if (isBridge(url)) {
      regesterBridge(ソケット、URL)
      戻る
    }

    const { ブリッジ、キー } = findBridge(リクエスト、URL)
    if (!bridge) 戻り値

    cacheClientRequest(ブリッジ、キー、ソケット、リクエスト、URL)

    キーによるブリッジへのリクエストの送信(キー)
  })
}).listen(80)

関数isBridge(url){
  url.startsWith('/regester?') を返します
}

関数regesterBridge（ソケット、URL）{
  定数キー = url.match(/(^|&|\?)key=(?<key>[^&]*)(&|$)/)?.groups?.key
  ブリッジ[キー] = ソケット
  socket.removeAllListeners('データ')
}

関数 findBridge (リクエスト、URL) {
  key = url.match(/\/(?<key>[^\/\?]*)(\/|\?|$)/)?.groups?.key とします。
  bridge = bridges[キー]とします
  if (bridge) return { bridge, key }

  const referer = request.match(/\r\nReferer: (?<referer>.+)\r\n/)?.groups?.referer
  if (!referer) が {} を返す

  キー = referer.split('//')[1].split('/')[1]
  bridge = 橋[キー]
  if (bridge) return { bridge, key }

  戻る {}
}

関数cacheClientRequest(ブリッジ、キー、ソケット、リクエスト、URL){
  if (クライアント[キー]) {
    クライアント[キー].requests.push({ブリッジ、キー、ソケット、リクエスト、URL})
  } それ以外 {
    クライアント[キー] = {}
    クライアント[キー].requests = [{ブリッジ、キー、ソケット、リクエスト、URL}]
  }
}

関数 sendRequestToBridgeByKey (キー) {
  const client = クライアント[キー]
  if (client.isSending) 戻り値

  const リクエスト = client.requests
  if (requests.length <= 0) 戻り値

  client.isSending = true
  クライアント.コンテンツ長 = 0
  クライアント受信 = 0

  const {ブリッジ、ソケット、リクエスト、URL} = リクエスト.shift()

  const newUrl = url.replace(キー、'')
  const newRequest = request.replace(url, newUrl)

  bridge.write(新しいリクエスト)
  ブリッジ.on('データ', データ => {
    定数レスポンス = data.toString()

    code = response.match(/^HTTP[S]*\/[1-9].[0-9] (?<code>[0-9]{3}).*\r\n/)?.groups?.code とします。
    if (コード) {
      コード = parseInt(コード)
      (コード === 200) の場合 {
        contentLength = response.match(/\r\nContent-Length: (?<contentLength>.+)\r\n/)?.groups?.contentLength とします。
        if (コンテンツの長さ) {
          コンテンツの長さ = parseInt(コンテンツの長さ)
          client.contentLength = コンテンツの長さ
          client.received = Buffer.from(response.split('\r\n\r\n')[1]).length
        }
      } それ以外 {
        socket.write(データ)
        client.isSending = false
        bridge.removeAllListeners('データ')
        キーによるブリッジへのリクエストの送信(キー)
        戻る
      }
    } それ以外 {
      クライアントが受信したデータ += データの長さ
    }

    socket.write(データ)

    (client.contentLength <= client.received) の場合 {
      client.isSending = false
      bridge.removeAllListeners('データ')
      キーによるブリッジへのリクエストの送信(キー)
    }
  })
}

これで、Nodejs によるイントラネット侵入サービスの実装に関するこの記事は終了です。より関連性の高い Node イントラネット侵入コンテンツについては、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: