소규모 네트워크 덤프의 인터넷 중단 분석

소규모 네트워크 덤프의 인터넷 중단 분석

여기에 이미지 설명을 입력하세요.

나는 때때로 인터넷 중단을 경험하므로 내 덤프가 아는 사람에게 이해가 되는지 묻고 싶었습니다. 여기에서 내가 보고 있는 내용에 대해 몇 가지 분석을 해주시기 바랍니다. 98.128.130.0은 내 ISP에 속해 있지만 내 ISP는 내가 왜 85.11.0.101을 가지고 있는지 이해하지 못합니다. 현재 내 인터넷은 제대로 작동하지만 오늘 온라인에 접속하기 시작하면 1분 후에 인터넷이 끊어졌습니다. 안정적인 연결이 거의 불가능한 경우도 있습니다. OS는 Ubuntu(컴퓨터 5대, 동일한 동작, 모두 Ubuntu, 다른 OS 없음), 라우터 없음, VPN 없음(VPN 3개 있음, VPN 유무에 관계없이 동일한 문제) 10m+1m 네트워크 케이블(케이블 교체(변경 없음)).

답변1

귀하의 라우팅 테이블

가지고 있는 것은 현재 라우팅 테이블뿐입니다. 나는 그것을 "네트워크 덤프"라고 부르지 않을 것입니다.저것일반적으로 tcpdumpWireshark 또는 유사한 도구를 사용하여 생성된 것입니다.

VPN이 활성화되면 모든 일반 트래픽은 일반적으로 암호화된 터널을 통해 라우팅됩니다. 실제로 VPN이 활성화되어 있는 동안 VPN 게이트웨이/집중 장치는 시스템의 새로운 기본 게이트웨이가 됩니다.

그러나 VPN 자체의 암호화된 트래픽은 VPN이 활성화되기 전에 유효했던 "일반" 게이트웨이에서 계속해서 시작되어야 합니다. 그렇지 않으면 VPN 소프트웨어가 무한 루프에 빠져 자체 암호화된 트래픽을 계속해서 다시 암호화하게 됩니다.

이를 방지하기 위해 VPN 소프트웨어는 VPN 게이트웨이 전용 대상과 넷마스크 255.255.255.255를 사용하여 직접 트래픽에 대한 경로를 추가하는 경우가 많습니다. 제대로 구현되지 않은 VPN 클라이언트는 VPN이 비활성 상태일 때 아무런 해를 끼치지 않기 때문에 연결이 끊어진 후 VPN 연결을 삭제하지 못할 수 있습니다.

간단히 말해서, 85.11.0.101은 일종의 VPN 연결의 잔재와 똑같거나 VPN을 명시적으로 우회하려는 시도와 똑같아 보입니다. 귀하의 VPN(또는 귀하가 실행 중인 소프트웨어) riksnet.se중 "Ratt Internet Kapacitet i Sverige AB"와 관련이 있습니까? 간단한 공개 WHOIS 조회를 기반으로 하면 IP 주소가 속한 회사입니다.

연결 문제 해결

인터넷 중단을 실제로 분석하려면 더 많은 정보가 필요합니다.

먼저, 귀하의 경우 실제로 실패의 원인이 무엇인지 이해하는 것이 가장 좋습니다. 물리적 링크가 실패했습니까? ISP 게이트웨이가 응답하지 않습니까? 아니면 ISP의 DNS 서버가 응답하지 않습니까?

다음 명령을 실행해 보세요.

sudo ethtool enp2s0

비밀번호를 묻고 네트워크 인터페이스의 현재 상태를 출력해야 합니다. 마지막 줄은 다음과 같습니다.

Link detected: yes

네트워크 연결이 끊어지면 명령을 다시 실행하고 출력을 "양호" 상태와 비교하십시오. 출력이 동일하면 물리적 링크가 확실히 안정적인 것입니다. sudo ethtool -S enp2s0네트워크 어댑터에서 사용할 수 있는 다양한 트래픽 통계를 살펴보세요. 네트워크가 다운될 때마다 _errors카운터 중 하나라도 증가하는 경우 _drops이는 케이블 연결이 불량하거나 네트워크 케이블 양쪽 끝에 있는 장치 간에 하드웨어 비호환성이 있을 수 있음을 나타냅니다.

하지만 좋아 보인다면 실행해보고 ping 98.128.130.1더 오랜 시간 동안 실행해 볼 수 있습니다. 일관된 반응을 얻고 있나요? 네트워크가 다운되면 출력이 변경됩니까? 게이트웨이가 핑 패킷에 전혀 응답하지 않는 경우 이 arping도구를 설치하고 사용해 보십시오. 이 도구는 ARP 패킷에 대해 유사한 테스트를 수행하며 일반적으로 이 기능을 비활성화할 수 있는 방법이 없습니다.

이상적으로는 네트워크 중단 시 (ar)ping 명령을 실행한 후 Ctrl+를 눌러 C명령을 중지하고 인쇄되는 통계의 마지막 몇 줄을 확인합니다. 패킷 손실이 0%보다 크면 시스템과 게이트웨이 사이에 네트워크 패킷 손실이 있음을 나타냅니다. 하지만 패킷이 손실된 경우0%이면 ISP와 나머지 국가 간의 격차이거나 문제가 완전히 다른 것입니다.

DNS 호스트 이름 확인 실패를 구별하는 방법을 모른다면 이는 네트워크 중단과 매우 비슷해 보입니다. DNS 문제 해결 명령 중 하나 또는 두 개가 설치되어 있는지 확인하십시오. nslookup또는dig 이 좋은 선택입니다. 때로는 이름이 불분명한 패키지에 들어 있는 경우도 있습니다. 예를 들어 bind-utils최신 데비안/우분투에서는 패키지에 넣어야 합니다 dnsutils.

네트워크가 "다운"된 경우 다음을 시도 nslookup www.google.com 8.8.8.8하십시오 dig www.google.com @8.8.8.8. 두 명령 모두 쿼리 중입니다.www.google.com Google의 자체 공개 DNS 서버에서 직접IP 주소는 8.8.8.8로 기억하기 쉽습니다. 네트워크가 "다운"되었음에도 불구하고 이러한 명령이 올바른 응답을 반환하는 경우 ISP의 확인자 DNS 서버가 불량한 것일 수 있습니다. 불행하게도 이런 상황은 그다지 드물지 않습니다. 그러나 이것이 실제로 문제의 원인이라면 해결 방법은 간단합니다. ISP에서 제공한 것이 아닌 다른 DNS 서버를 사용하도록 시스템을 구성하기만 하면 됩니다.

관련 정보