홈 LAN에서 라우터를 다시 시작한 후 노트북 A에서 노트북 B로 SSH를 통해 연결할 수 없습니다.와는 별개로라우터를 통해. 하지만 노트북 B에서 노트북 A로 ping을 한 후에는 정상적으로 A에서 B로 연결할 수 있습니다. 라우터를 다시 시작하면 이 문제를 재현할 수 있습니다. 두 노트북 모두 Wi-Fi를 통해 라우터에 연결되어 있으며 다른 AP나 라우터에는 연결되어 있지 않습니다. LAN에 다른 장치가 있는데 다른 ARP 문제는 모르겠습니다.
라우터를 다시 시작한 후 문제를 시연합니다.
scott@laptopa:~$ ip addr show dev wlp58s0 |grep 'inet '
inet 192.168.8.194/24 brd 192.168.8.255 scope global dynamic noprefixroute wlp58s0
scott@laptopa:~$ ssh 192.168.8.131 echo okay
ssh: connect to host 192.168.8.131 port 443: No route to host
scott@laptopa:~$ ssh 192.168.8.131 echo okay
ssh: connect to host 192.168.8.131 port 443: No route to host
scott@laptopa:~$ ssh 192.168.8.131 echo okay
ssh: connect to host 192.168.8.131 port 443: No route to host
scott@laptopa:~$ arp |grep 9c:b6:d0:44:18:09
scott@laptopa:~$
어색한 해결책:
scott@laptopa:~$ ssh -o 'ProxyCommand ssh -q -W %h:%p [email protected]' 192.168.8.131 'ping -c 10 192.168.8.194'
PING 192.168.8.194 (192.168.8.194) 56(84) bytes of data.
64 bytes from 192.168.8.194: icmp_seq=1 ttl=64 time=66.3 ms
64 bytes from 192.168.8.194: icmp_seq=2 ttl=64 time=22.9 ms
64 bytes from 192.168.8.194: icmp_seq=3 ttl=64 time=106 ms
64 bytes from 192.168.8.194: icmp_seq=4 ttl=64 time=230 ms
64 bytes from 192.168.8.194: icmp_seq=5 ttl=64 time=252 ms
64 bytes from 192.168.8.194: icmp_seq=6 ttl=64 time=275 ms
64 bytes from 192.168.8.194: icmp_seq=7 ttl=64 time=298 ms
64 bytes from 192.168.8.194: icmp_seq=8 ttl=64 time=321 ms
64 bytes from 192.168.8.194: icmp_seq=9 ttl=64 time=38.3 ms
64 bytes from 192.168.8.194: icmp_seq=10 ttl=64 time=60.3 ms
--- 192.168.8.194 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9012ms
rtt min/avg/max/mdev = 22.950/167.478/321.937/112.761 ms
지금 작동하는지 증명하세요.
scott@laptopa:~$ ssh 192.168.8.131 echo okay
okay
scott@laptopa:~$ arp |grep 9c:b6:d0:44:18:09
laptopb.lan ether 9c:b6:d0:44:18:09 C wlp58s0
노트북 A와 B는 모두 Ubuntu 18.04를 실행하고 있으며 라우터는 Lede(OpenWRT) 17.01.4입니다.
답변1
@roaima가 제안한 대로 모든 규칙을 삭제 iptables
하고 다시 테스트했습니다. 라우터를 여러 번 다시 시작한 후에도 문제가 전혀 없었습니다. 그런 다음 iptables
규칙을 다시 추가하고 추가 테스트를 했습니다. 여전히 문제가 없습니다.
간단히 말해서 문제를 더 이상 재현할 수 없으므로 @dirkt가 경험한 것처럼 무작위일 수도 있습니다. 네트워크의 다른 장치일 수도 있습니다.