어느 방향으로 조사해야할지 혼란 스럽습니다 ...
Server1은 모든 컴퓨터에 SSH를 통해 연결할 수 있지만 다른 컴퓨터는 Server1에 SSH를 통해 연결할 수 없습니다. Server1 ssh에서 Server2 -> Server2도 동일한 개방형 SSH 포트를 통해 Server1로 다시 SSH를 통해 연결할 수 없습니다.
Server1은 SSH 터널을 통해 Server3으로 SSH를 연결한 다음 Server2로 SSH를 통해 연결할 수 있습니다.
서버 1 => 서버 3 => 서버 2
Server1이 Server2를 통해 Server3으로 터널링할 수 있지만 Server3을 통해 Server1로 다시 터널링할 수 없는 이유는 무엇입니까?
크로스오버 케이블을 통해 연결된 경우 Server1은 Server2에 직접 연결할 수 있지만 Server2에서 Server1로 다시 터널링할 수는 없습니다.
서버 1 => 서버 2 => [X] 서버 1
라우터에 연결된 경우
# ssh 192.168.4.1
# ssh: connect to host 192.168.4.1 port 22: Connection refused
# nc 192.168.4.1 22 (does not connect)
# nc -l 22 (on 192.168.4.1)
# nc: Address already in use
서버 1: 192.168.4.2
서버 2: 192.168.4.1
서버 3: 192.168.4.3
테스트하는 동안 방화벽을 비활성화하십시오. IP 테이블은 모두 허용됩니다. 라우팅 테이블 구성 오류가 의심됩니다...
Server1 커널 IP 라우팅 테이블
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 wlan0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
192.168.4.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
192.168.4.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
편집: 이전 작업 저장의 "#route -n" 출력을 보면 192.168.4.0(서버의 서브넷)의 메트릭은 100입니다. Route -n에 표시된 메트릭 설정이 SSH 터널을 차단할 가능성이 있습니까?
편집하다:
# tcpdump -c 25 -i eth0 -v
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
19:19:37.121131 IP (tos 0x10, ttl 64, id 19952, offset 0, flags [DF], proto TCP (6), length 176)
homie.ssh > 192.168.4.6.38360: Flags [P.], cksum 0x89fb (incorrect -> 0xecf8), seq 3089869718:3089869842, ack 4078834853, win 271, options [nop,nop,TS val 11868537 ecr 3677449774], length 124
19:19:37.121627 IP (tos 0x10, ttl 64, id 22362, offset 0, flags [DF], proto TCP (6), length 52)
192.168.4.6.38360 > homie.ssh: Flags [.], cksum 0x8577 (correct), ack 124, win 501, options [nop,nop,TS val 3677449895 ecr 11868537], length 0
19:19:37.135066 IP (tos 0x10, ttl 64, id 19953, offset 0, flags [DF], proto TCP (6), length 184)
homie.ssh > 192.168.4.6.38360: Flags [P.], cksum 0x8a03 (incorrect -> 0xe8ff), seq 124:256, ack 1, win 271, options [nop,nop,TS val 11868540 ecr 3677449895], length 132
19:19:37.135254 IP (tos 0x0, ttl 64, id 37912, offset 0, flags [DF], proto UDP (17), length 70)
homie.57077 > gateway.domain: 17930+ PTR? 6.4.168.192.in-addr.arpa. (42)
19:19:37.135317 IP (tos 0x10, ttl 64, id 22363, offset 0, flags [DF], proto TCP (6), length 52)
답변1
노선
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
192.168.4.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
192.168.4.0 0.0.0.0 255.255.252.0 U 0 0 0 eth0
동일한 서브넷은 두 개의 서로 다른 네트워크 마스크를 가질 수 없습니다.
두 개의 서로 다른 서브넷이 모두 동일한 게이트웨이 0.0.0.0을 가리키는 경우 내부 게이트웨이에 대한 트래픽 바인딩이 "손실"됩니다.
# sudo route del -net 192.168.4.0 gw 0.0.0.0 netmask 255.255.255.0 dev eth0
이제 두 네트워크를 별도로 사용해 보십시오. 경로는 자동으로 생성되므로 자체적으로 "그냥" 작동합니다. 그렇지 않은 경우 원격 IP(서버) 192.168.4.0/24에 경로를 수동으로 추가하면 작동하지 않는 것 같습니다. 누군가 이유를 설명할 수 있을 것입니다.
`# route add -net 192.168.4.0 netmask 255.255.254.0 gw 192.168.4.2 eth0'
이 문제를 파악하는 데 며칠이 걸렸으므로 참고용으로 여기에 게시하면 비슷한 문제가 있지만 ssh는 없지만 ping에 대한 문제 해결 단계를 찾는 사람에게 도움이 될 것입니다.