몇 달 전에 저는 Linux, PureOS, 그리고 지금은 Debian 10으로 옮겼습니다. 전반적으로 마음에 들었고 올바른 결정이었지만 네트워크가 여러 차례 완전히 실패하는 등 몇 가지 실망스러운 문제에 직면했고 이를 해결할 수 있는 유일한 방법은 재부팅이었습니다.
- 일시 중지 후(항상 반복할 수는 없음)
- USB 무선 어댑터를 분리한 후
나의 행동과 내가 시도한 것들
관찰된 동작은 다음과 같습니다(누락된 정보에 대해 미리 사과드립니다. 네트워킹은 저의 강점이 아니며 여전히 해결책을 찾고 있으므로 제가 해온 작업이 완전히 잘못되었을 수 있습니다!)
WiFi가 제대로 작동하고 네트워크에 연결된 것 같지만 발신 요청을 할 수 없습니다. 이상하게도 이것은 ping
실패합니다.
ping: sendmsg: Operation not permitted
카드는 드라이버 Atheros AR9462를 사용하고 있습니다 ath9k
(아래 출력 lspci
).
01:00.0 Network controller: Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01)
Subsystem: Lite-On Communications Inc AR9462 Wireless Network Adapter
Flags: bus master, fast devsel, latency 0, IRQ 16
Memory at d1000000 (64-bit, non-prefetchable) [size=512K]
Expansion ROM at d1080000 [disabled] [size=64K]
Capabilities: <access denied>
Kernel driver in use: ath9k
Kernel modules: ath9k
카드가 제대로 작동하더라도 "액세스 거부"가 계속 표시됩니다.
출력 ip addr
:
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
6: wlp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 30:10:b3:06:0d:46 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.2/24 brd 192.168.0.255 scope global dynamic noprefixroute wlp1s0
valid_lft 86324sec preferred_lft 86324sec
inet6 2a02:c7f:607d:c200:de25:b539:67b5:e1e0/64 scope global dynamic noprefixroute
valid_lft 2917sec preferred_lft 2917sec
inet6 fdf3:9d9f:4b19:0:7164:9b0f:40fa:1f9c/64 scope global noprefixroute
valid_lft forever preferred_lft forever
inet6 fe80::4d60:c6e4:9b2a:a0ab/64 scope link noprefixroute
valid_lft forever preferred_lft forever
그리고 ip route
:
default via 192.168.0.1 dev wlp1s0 proto dhcp metric 600
169.254.0.0/16 dev wlp1s0 scope link metric 1000
192.168.0.0/24 dev wlp1s0 proto kernel scope link src 192.168.0.2 metric 600
네트워크를 잊어버리고 다시 연결해도 문제가 해결되지 않습니다. 이 기계에는 PCI 무선을 비활성화하는 하드웨어 스위치가 있으며 이를 전환해도 도움이 되지 않습니다. DHCP 임대 갱신에 실패했으며, 다음 방법을 통한 네트워크 서비스 재시작도 실패했습니다.
sudo systemctl restart NetworkManager.service
modprobe
커널을 사용하여 무선 드라이버를 제거하고 다시 등록하기 위해 위 단계를 조합하여 사용해 보기도 했습니다.
터미널을 통해 VPN 서비스를 사용하고 있는데 nordvpn
연결 문제가 발생한 후 nordvpn
명령이 실패합니다(Ctrl-C를 요구하는 명령 프롬프트에서 응답이 없음) . 프로세스 kill
를 다시 시작해 nordvpn
도 문제가 해결되지 않습니다.
편집: 차단을 유발하는 이상한 규칙은 없습니다.iptables
ping
iptables
사용자 AB(아래 설명 참조) 덕분에 이제 기본 정책을 사용하여 DROP으로 업데이트되었으며 VPN 프로세스가 원인일 가능성이 높다는 것을 깨달았습니다 . 추가로 테스트하고 문제를 재현/수정할 수 있으면 질문을 편집하겠습니다.
Chain INPUT (policy DROP)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy DROP)
target prot opt source destination
무슨 일이 일어나는지
따라서 네트워크 연결을 복원하는 유일한 방법은 재부팅하는 것입니다. 이상하게도 재부팅 후 터치패드가 완전히 반응하지 않는 경우가 있어서 두 번 재부팅해야 했습니다.
위의 내용은 꽤 짜증나고 아마추어로서 이 문제를 해결하기 위해 노력했습니다. 어떤 조언이라도 주시면 매우 감사하겠습니다! 미리 감사드립니다.
답변1
iptables
DROP
지속적인 정책으로 인해 연결 부족이 발생했음을 지적한 사용자 AB(댓글 참조)에게 많은 감사를 드립니다. 이는 문제가 있을 때 시스템을 기본값으로 재설정하지 않는 NordVPN 서비스의 버그인 것 같습니다. 여기 다른 사람이 동일한 문제에 직면할 경우를 대비해 제안된 대로 여기에 솔루션을 게시하세요.
문제가 발생하면 다음과 같이 sudo iptables -L
표시됩니다.
Chain INPUT (policy DROP)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy DROP)
target prot opt source destination
nordvpn
프로세스를 종료 한 다음 iptables
적절하게 규칙과 정책을 재설정합니다.디지털 바다에 대한 이 가이드문제를 해결했습니다.
# Kill the nordvpn process
ps aux | grep nordvpn
kill -9 NORDVPND_PROCESS_NUMBER
# reset the default policies
# NB all iptables commands require root (sudo)
iptables --policy INPUT ACCEPT
iptables --policy FORWARD ACCEPT
iptables --policy OUTPUT ACCEPT
# flush the nat and mangle tables
iptables -t nat --flush
iptables -t mangle --flush
# flush all chains, and delete all non-default chains
iptables --flush
iptables -X