ターゲットサーバーがあり、現在ネットマスクが255.0.0.0に誤って設定されています。正しいネットマスクは255.255.255.128です。私のソースサーバーも/ 25ネットワークなので、両方とも同じサブネットマスクを持っていますが、どちらも2つの異なるVLANに属します。
私の質問は次のとおりです。
異なるVLANおよびIP範囲（たとえば157）に属する他のサーバーを介してターゲットサーバーに正常に接続できます。。。ただし、10.10.126ではターゲットサーバーに接続できません。。ターゲットサーバーでルートトレースを実行すると、サーバーはソースIPが独自のローカルサブネットに属していることをローカルで確認することがわかりました。ネットマスクが正しく構成されていない場合、157.* サーバーの SSH 接続を許可するのはなぜですか。どうやってやるの？
現在誤った設定：
Destination server: 10.10.127.* netmask 255.0.0.0
現在正しい設定：
Source server: 10.10.126.* Mask:255.255.255.128
テスト用tcpdump：
[root@Destination_server ~]# tcpdump -vvv -i eno16780032 host 10.10.126.*
tcpdump: listening on eno16780032, link-type EN10MB (Ethernet), capture size 65535 bytes
21:36:28.403812 IP (tos 0x0, ttl 64, id 48314, offset 0, flags [DF], proto TCP (6), length 60)
10.10.126.*.60692 > Destination_server.ssh: Flags [S], cksum 0x3c87 (correct), seq 379301407, win 29200, options [mss 1380,sackOK,TS val 495338
91 ecr 0,nop,wscale 7], length 0
21:36:28.403928 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:29.400303 IP (tos 0x0, ttl 64, id 48315, offset 0, flags [DF], proto TCP (6), length 60)
10.10.126.*.60692 > Destination_server.ssh: Flags [S], cksum 0x3b8d (correct), seq 379301407, win 29200, options [mss 1380,sackOK,TS val 495341
41 ecr 0,nop,wscale 7], length 0
21:36:29.406300 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:30.408295 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:31.405136 IP (tos 0x0, ttl 64, id 48316, offset 0, flags [DF], proto TCP (6), length 60)
10.10.126.*.60692 > Destination_server.ssh: Flags [S], cksum 0x3998 (correct), seq 379301407, win 29200, options [mss 1380,sackOK,TS val 495346 42 ecr 0,nop,wscale 7], length 0
21:36:35.412611 IP (tos 0x0, ttl 64, id 48317, offset 0, flags [DF], proto TCP (6), length 60)
10.10.126.*.60692 > Destination_server.ssh: Flags [S], cksum 0x35ae (correct), seq 379301407, win 29200, options [mss 1380,sackOK,TS val 495356 44 ecr 0,nop,wscale 7], length 0
21:36:35.412738 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:36.414276 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:37.416282 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:43.428318 IP (tos 0x0, ttl 64, id 48318, offset 0, flags [DF], proto TCP (6), length 60)
10.10.126.*.60692 > Destination_server.ssh: Flags [S], cksum 0x2dda (correct), seq 379301407, win 29200, options [mss 1380,sackOK,TS val 495376 48 ecr 0,nop,wscale 7], length 0
21:36:43.428457 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:44.430268 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
21:36:45.432280 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 10.10.126.* tell Destination_server, length 28
答え1
目的地に到達するために3番目のサーバーを使用できますか？
理論によると。
3番目のサーバーは、失敗したサーバーと同じサブネット上になければなりません。
デフォルトでは、「実際の」サブネットが/ 25（255.255.255.128）で失敗したサーバーIPが10.10.127.10の場合、10.10.127.0から10.10.127.125の間で誰にでも接続できます。これらのアドレスは、障害のあるサーバーと同じネットワークにあります。
なぜ
基本的に考慮すべき2つのシナリオがあります。サーバーにIP、ネットマスク、ゲートウェイがあるとします。 DNS検証が省略されました。単純化する...
サブネット内
ネットワーク上のホストにアクセスしようとすると、システムを離れる最初のパケットはARPになり、「who-has my-ip-address」メッセージをブロードキャストします。
これに応答して、ピアのハードウェアアドレスが返されたメッセージ「is-at 00:11:22:...」を受信できます。これにより、メッセージがホストからリモートデバイスに直接送信されます。
最初のユースケースは、同じLAN（またはVLAN）内の通信にのみ適用されます。
リモートサブネット
通常、一部のリモートサービスにアクセスしようとします。宛先のIPアドレスがローカルネットワークに属していない場合、送信元サーバーはそのトラフィックをデフォルトゲートウェイに転送します。
同様に、ゲートウェイのハードウェアアドレスを確認するためのいくつかのARP検証の試みを見ることができます（デフォルトのゲートウェイであるにもかかわらず、ハードウェアアドレスはすでにARPキャッシュに存在する可能性があります）。
そこで、私たちのターゲットはルータに接続された特定のサブネットに属し、サブネット内の状況に戻ります。それ以外の場合、ルータはトラフィックをゲートウェイに転送します。
157.2.3.5にアクセスできるのはなぜですか？
157.2.3.5が10/8の一部ではないことを考慮すると、その接続は通常通りゲートウェイを通過します。
/ 25の代わりに/ 8でサーバーを構成すると、デフォルトでそのサーバーと/ 25の代わりにこの/ 8に含まれるすべての項目間の通信が失われます。障害のあるサーバーは、これらのネットワークがローカルネットワークであると誤って考えているため、ARP検証を試みますが、応答はありません。
リモコンが10.10.127.0/25または10/8以外のアドレスに属している場合、接続の問題は発生しません。