TL;DR(最初の方法のみ)

デスクトップから：

ip route add 192.168.10.0/24 dev eth0 table 1000
ip route add default via 192.168.10.1 dev eth0 table 1000
ip rule add iif lo ipproto tcp sport 22 lookup 1000

質問

ここで問題はデスクトップで発生します。

さまざまなレイアウトにより、NUCはすべてのトラフィックを確実にブロックできるため、より簡単な方法を使用できます。同じイーサネットLANに2つのIP LANをルーティングしてもDHCPなどの問題は回避されないため、NUCには2つのネットワークデバイスが必要です。 NUCをステートフルブリッジとして使用することも、2つのNICを必要とする別のソリューションです。

現在のレイアウトでは、NUCはAPとデスクトップ間のすべてのトラフィックを傍受できません。

...解決策はデスクトップで実行する必要があります。

Linuxが利用可能ポリシールーティングセレクタは、パケットに異なる結果を提供するために使用されます（他のルーティングテーブルを使用して）。明らかに、同じ宛先に対して複数のパスを使用することに関連するすべての問題には、主にソースに基づいて分離できるセレクタを使用するポリシールーティングを使用する必要があります（ここでは、ルーティングテーブルがすでにターゲットを区別するために使用されているため）。

デスクトップへのSSH接続に関連して異なる結果（別のパスなど）を生成できるように、APから直接着信パケットとNUCから着信パケットを分離する必要があります。

利用できないように見えるのは、そのルートがip rule使用されているゲートウェイと異なる場合、2つのルートを介して到着する2つのパケットを区別するためのセレクタです。 Linuxのポリシールールはそれを捉えていないようです。同じインターフェイスから出てくる限り同じです。

私は次のように仮定します：

• デスクトップネットワークインターフェイスは次のとおりです。イーサネット0。
• デスクトップはルーター（例：libvirt、LXC、Docker）ではありません。ルーティングには、実行する必要があるタスクのより多くの設定と選択が必要です（VMはNUCまたはAPからSSHを受信する必要がありますか？）。以下の回答では、ルーティングケースの例外を正しく生成するためにいくつかの調整が必要です。それ以外の場合、コンテナ/ VMはデフォルトパス（たとえば、NUCを介して）に従います。

これには2つの方法があります。

ポリシールーティングはレイヤ4プロトコル（TCPポート22）と一致します。

~からLinux 4.17セレクタを使用して、TCP ポート 22 のポリシー ルーティングを一致させることができます。これにより、他のルートを利用するのは簡単です。パケットソースを別の方法で処理するのではなく、この特定のポートを別の方法で処理してください。

ip route add 192.168.10.0/24 dev eth0 table 1000
ip route add default via 192.168.10.1 dev eth0 table 1000
ip rule add iif lo ipproto tcp sport 22 lookup 1000

iif lo実際にはそうではありませんルオインターフェイスですが、特定の文法的意味ローカルシステムで。 LANパスも複製する必要があります。たとえば、NUC 自体の SSH 接続は AP を介して応答し、設定エラーを通知する ICMP リダイレクトを発行します。この場合は同じインターフェイスなので、受信したパケットへの代替パスを指定するためのルールは必要ありません。他のインターフェースの場合SRPFできるようにする（rp_filter=1) はルールの実際の異なるインターフェイスにip rule add iif eth0 ipproto tcp dport 22 lookup 1000置き換えられ、デフォルトパスも必要です。eth0

これは目標を達成するために3つのコマンドしか必要としない非常に簡単な方法です。

VPN が着信トラフィックを許可している場合は、一部の特定の LAN で SSH を受信したり、NUC からアドレス ブロックを受信するように調整したりできますが、いずれの場合も、両方の IP を使用する同じパブリック IP では許可されません。ソースは、ターゲットの指定中にSSH接続を許可します。 /路線。

APのMACアドレスとタグを使用したポリシールーティング

以前の方法とは異なり、着信パケットを NUC ではなく AP ゲートウェイから来るものとして識別する間接的な方法、つまりイーサネット ソース MAC アドレスがあります。

これはポリシールーティングでは直接使用できませんが、ファイアウォールタグを使用して着信パケットを表示できます。表示できるポリシールーティングに使用され、応答パケットにこの指示を設定する方法はいくつかあります。

着信部分と応答する部分を分けてみましょう。これは特定のタイプの着信トラフィックに依存しないため、後でAPからデスクトップに転送される他のポートを処理するために変更する必要はありません。

私は次のことを仮定します：

• APのMACアドレス（ping後にデスクトップに表示されるip neigh show 192.168.10.1）の値は02:00:00:ac:ce:55です。以下でこの値を変更してください。

受信と共通設定

人々はNetfilterがどのように機能するかを見なければなりません。iptablesルーティングと相互作用この図:

一つiptablesraw/PREROUTINGのルールはパケットを表示します。その後、以前と同様の方法でポリシールーティングを実行します。

iptables -t raw -A PREROUTING -i eth0 -m mac --mac-source 02:00:00:ac:ce:55 -j MARK --set-mark 1

ip route add default via 192.168.10.1 table 1000 
ip rule add fwmark 1 lookup 1000

返信する

返信を処理する方法は2つあります。

• シンプルで自動です。、TCPのみ

  TCPでのみ使用でき、UDPを含む他のプロトコルでは使用できません。

  宛先はTCPポート22なので、OPの場合はこれで十分です。ただ完了着信部分:

  sysctl -w net.ipv4.tcp_fwmark_accept=1
  sysctl -w net.ipv4.fwmark_reflect=1
  

  説明する：

  • tcp_fwmark_accept

    TCPあたりソケットSO_MARK新しい接続を受け入れると、生成されたソケットオプションは、この接続にのみソケットオプションが使用されているかのように、最初のパケットのフラグを継承します。特に、ここでフラグが設定されると、ルーティングテーブル１０００を使用して、すべての応答トラフィックが、着信トラフィックが到着した同じゲートウェイを介して再ルーティングされる。

  • fwmark_反射

    同様に、カーネルによって直接処理される応答パケット（たとえば、ICMPエコー応答またはTCP RST、および一部のTCP FINの場合）は、着信パケットのタグを継承します。たとえば、TCPソケットの受信がない場合（デスクトップのSSHサーバーが停止している場合など）、これが発生する可能性があります。このフラグが存在しない場合は、AP を介した SSH 接続試行が接続されるのではなくタイムアウトします。接続が拒否されました。これは、TCP RST が NUC を介してルーティングされ、リモートクライアントでは無視されるためです。

  あるいはその逆も…

• 一般加工乗り継ぎで表示パケットとつながる返信を入力して返すバッグ

  ㅏ表示として記録することができるコマック中つながるこれをmangle / OUTPUTにコピーして、ストリーム内の他のすべてのパケット（応答パケットを含む）に影響を与えます。つながる到着表示。終わる着信部分:

  iptables -t mangle -A PREROUTING -m mark --mark 1 -j CONNMARK --set-mark 1
  iptables -t mangle -I OUTPUT -m connmark --mark 1 -j MARK --set-mark 1
  

  これはすべての場合（TCP RSTとUDPを含む）を処理します。したがって、着信TCPまたはUDPトラフィックをデスクトップに転送するようにAPを設定できます。このブログの他のドキュメント。

様々な種類

ガイドライン

• アドレスが削除された後に再度追加されるか、インターフェイスがハングした後にアクティブになると、手動で追加された関連ルートは削除され、再表示されません。したがって、手動ip routeコマンドは、少なくともネットワーク接続が確立されるたびに追加されるようにデスクトップネットワーキングを構成するツールと統合する必要があります。

• 各ツールには、高度なネットワーク構成に対するさまざまなアプローチがあるため、完全ではない可能性があります。たとえば、Ubuntuネットワーク計画routing-policyまたは使用可能な場合は、その設定iif loに文書化されませんipproto tcp sport 22。利用できない機能を置き換えるには、カスタムスクリプトを使用できるツールを好む必要があります（例：ifupdownまたはNetworkManagerこれを行うことができます）。

• Nitpicking：VPNが着信トラフィックを許可する場合、単一のリモート（パブリック）IPアドレスが2つのルート（2つの異なるパブリックIPアドレスと見なされる）を使用して同じデスクトップサービスに2回接続される最後の方法を使用する非常に複雑です。どちらの宛先にも同じ送信元ポートを使用すると、デスクトップに同じトラフィックが2回だけ表示され、混乱します（2つのUDPがマージされ、2番目のTCPが失敗する）。これは通常、ルーティング時に処理できます（次を使用）。接続エリアおよび/または自動的につながるソースポートの変更）は、ここでホストの状況でこの問題を処理できない可能性があります。

ボーナス

デスクトップが実際にルーターである場合は、タグとCONNTRACKを使用する最後の方法を変更する必要があります。コンテナへのパスはテーブル1000にコピーする必要があります。これは機能しますが、Dockerではテストされていません（追加の問題が発生する可能性があります）。

ここでは、次のように仮定します。

• デスクトップは、次のインターフェイスを介してLAN 172.17.0.0/16のNATedコンテナをルーティングします。br0（Dockerはドッカー0デフォルトネットワークの場合）ローカルIPアドレスは172.17.0.1/16です。
• デスクトップDNATは、特定のポートをこれらのコンテナに接続します。

多様性:

• ルールとパス

  コンテナへのパスは、デフォルトのルーティングテーブルからテーブル1000にコピーする必要があります。コンテナ/仮想化ツールが新しいインターフェイスとパスを動的に追加する場合、テーブル（1000）にも追加するには、新しいパスを手動で追加する必要があります（またはツールの一部のAPIによってトリガされるいくつかのスクリプトメカニズムを使用して）。

  ip route add 172.17.0.0/16 dev br0 table 1000
  

  これがない場合は、APを介して着信接続とマークされている（次の箇条書きにあります）がルーティングされます。後ろにAP通信に。

• MAC アドレスの以前のルールの維持生のテーブル。

• 古いルールの削除壊すテーブル

  iptables -t mangle -F
  

• このルールを次のように変更してください。

  iptables -t mangle -A PREROUTING -m mark ! --mark 0 -j CONNMARK --save-mark
  iptables -t mangle -A PREROUTING -m connmark ! --mark 0 -j CONNMARK --restore-mark
  iptables -t mangle -A OUTPUT -m connmark ! --mark 0 -j CONNMARK --restore-mark
  

  （この単一のマーカーでは、より多くの動作を犠牲にしていくつかの最適化を実行できます）

  最初のPREROUTINGルールは、conntrackマークがゼロ値のパケットマークで上書きされないようにします。 2番目のPREROUTINGルールは、元のAPを介して確立されたフローのコンテナ（個々のパケットは最初にタグ付けされていない）部分でルーティングされたトラフィックの表示を設定します。