Sự cố mạng Linux: các bước tốt nhất để tìm hiểu nguyên nhân?

Một trong những máy chủ Linux (CentOS) của chúng tôi không thể truy cập tối qua.

Máy chủ không thể truy cập theo bất kỳ cách nào ngoại trừ bảng điều khiển từ xa. Sau khi đăng nhập bằng bảng điều khiển từ xa, hóa ra tôi cũng không thể ping bất kỳ máy chủ bên ngoài nào.

Một cách đơn giản đã service network restartgiải quyết vấn đề, nhưng tôi vẫn đang tự hỏi điều gì có thể gây ra điều này. Các tệp nhật ký của tôi dường như cho thấy không có lỗi nào cả (ngoại trừ các trình tiện ích khác nhau cần kết nối mạng và bị lỗi sau khi lỗi mạng).

Có bất kỳ bước bổ sung nào tôi có thể thực hiện để tìm hiểu nguyên nhân của vấn đề này không?

EDIT : điều này vừa xảy ra một lần nữa. Máy chủ hoàn toàn không phản hồi cho đến khi tôi ban hành dịch vụ mạng khởi động lại. Mọi lời khuyên đều được chào đón. Điều này có thể được gây ra bởi một thành phần phần cứng bị lỗi?

Theo yêu cầu của Madhatters, đây là một số trích đoạn từ nhật ký tại thời điểm đó (mạng bị sập lúc 20:13):

/ var / log / tin nhắn:

Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=100 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:01:05 graviton kernel: Firewall: *TCP_IN Blocked* IN=eth0 OUT= MAC=<stripped> SRC=<stripped> DST=<stripped> LEN=40 TOS=0x00 PREC=0x00 TTL=101 ID=256 PROTO=TCP SPT=6000 DPT=3306 WINDOW=16384 RES=0x00 SYN URGP=0
Dec  2 20:13:34 graviton junglediskserver: Connection to gateway failed: xGatewayTransport - Connection to gateway failed.

Ba thông báo đầu tiên là các phản hồi đơn giản đối với các quy tắc iptables mà tôi đã thiết lập thông qua tường lửa LFD. Thông báo cuối cùng chỉ ra rằng JungleDisk, mà tôi sử dụng để sao lưu không thể kết nối với cổng nữa. Ngoài ra, không có tin nhắn thú vị trong thời gian này.

EDIT 4 dec: theo yêu cầu của Mattdm, đây là đầu ra của ethtool eth0:

(Xin lưu ý rằng đây là các cài đặt hiện đang hoạt động . Nếu sự cố xảy ra lần nữa, tôi chắc chắn sẽ đăng lại nếu cần thiết.

Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 1
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: g
        Wake-on: d
        Link detected: yes

Theo yêu cầu của Joris, đây cũng là đầu ra của route -n:

aron@graviton [~]# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
xx.xx.xx.58    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.42    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.43    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.41    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.46    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.47    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.44    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.45    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.50    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.51    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.48    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.49    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.54    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.52    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.53    0.0.0.0         255.255.255.255 UH    0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.192 U     0      0        0 eth0
xx.xx.xx.0     0.0.0.0         255.255.255.0   U     0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0
0.0.0.0         xx.xx.xx.62    0.0.0.0         UG    0      0        0 eth0

Xx.62 dưới cùng là cổng của tôi.

EDIT ngày 28 tháng 12: sự cố lại xảy ra và tôi có cơ hội so sánh một số kết quả đầu ra của các bài kiểm tra trên. Những gì tôi phát hiện ra là arp -antrả về một địa chỉ MAC không đầy đủ cho cổng của tôi (không thuộc quyền kiểm soát của tôi; máy chủ nằm trong một giá chung):

Trong thời gian thất bại:

? (xx.xx.xx.62) at <incomplete> on eth0

Sau service network restart:

? (xx.xx.xx.62) at 00:00:0C:9F:F0:30 [ether] on eth0

Đây có phải là thứ tôi có thể sửa hay đã đến lúc tôi liên hệ với trung tâm dữ liệu?

kiểm tra

dmesg | lesscho bất cứ điều gì liên quan đến bí danh nic của bạn (ví dụ eht0) less /var/log/messageslà tốt

Mặc dù hiếm khi xảy ra xung đột địa chỉ IP, nếu điều này xảy ra một lần nữa hãy thử

arping -U <gateway ip> -I <nic alias> Tuy nhiên, hãy kiểm tra điều này vì đã lâu tôi mới sử dụng arping và điều này có thể không chính xác.

Nếu thành công, bạn nên lấy lại kết nối mà không cần tải lại dịch vụ mạng.

Làm thế nào bạn nhận được địa chỉ IP của bạn trên mạng này (DHCP hoặc tĩnh)? Nếu nó xảy ra lần nữa, hãy đảm bảo chạy ifconfigđể xem trạng thái của giao diện trong khi nó ở trạng thái không hoạt động. Nó có địa chỉ không? Có lỗi không? Nếu bạn chạy ethtool, có một liên kết? (Và nó có được thương lượng đúng tốc độ và song công không?)

Dựa trên các vấn đề gặp phải, tôi rất nghi ngờ về xung đột địa chỉ IP. Khởi động lại mạng sẽ gửi một ARP vô cớ sẽ chiếm lại IP đó, điều này sẽ làm sáng tỏ mọi thứ.

Tôi sẽ cài đặt arpwatch trên một máy chủ khác trong cùng miền phát sóng (cùng mạng) và xem liệu có máy nào khác đang phản hồi yêu cầu ARP cho IP của máy chủ của bạn không. Nếu vậy, hãy tìm ra máy nào (có thể sử dụng bảng địa chỉ MAC từ các thiết bị chuyển mạch của bạn để tìm ra cổng nào được gắn vào) và đặt nó thành một địa chỉ tĩnh hoặc DHCP khác.

Có lẽ nhóm kết nối TCP đã đầy? Một cái gì đó đang mở ngày càng nhiều kết nối, có thể đang thử netstat(thử các tùy chọn khác nhau, ví dụ -i để xem giao diện) sẽ cung cấp cái nhìn sâu sắc về kết nối mở.

Nếu các kết nối thực tế (và iptables / tuyến / bất cứ điều gì: cấu hình you_are_USE) đều ổn, ví dụ như vấn đề trong cấu hình giao diện mạng.

Là ifconfig -ađầu ra của bạn lành mạnh? Đầu ra đó sẽ cho biết nếu bạn có một số thiết bị mạng không nên có mặt, ví dụ như các thiết bị ảo, điều đó sẽ khiến các gói bị hỏng.

Bảng định tuyến này bạn đã dán trông thật lạ. Nó có hoạt động khi nó như vậy không, và nó có thay đổi sau khi kết nối ngừng hoạt động không? Nếu có, một cái gì đó đang khiến bảng định tuyến thay đổi, có thể là thứ gì đó liên quan đến iptables.

Cuối cùng, điều cụ thể của CentOS: bạn có sử dụng NetworkManager không? Nó được bật theo mặc định trong CentOS vì một số lý do, ngay cả trong các máy ảo không có X, làm cho kết nối này tăng gấp đôi, thay đổi định tuyến và những thứ khác có thể. Tôi khuyên bạn nên tắt nó đi trừ khi bạn biết bạn cần nó (như, có kết nối bật và tắt).

Vấn đề này đã được giải quyết cách đây khá lâu: vấn đề rõ ràng là liên quan đến phần cứng.

Một NIC mới đã giải quyết được vấn đề.

Bạn đang thử nghiệm ở đâu? Trong mạng con hoặc bên ngoài của nó? Bạn có bao nhiêu tuyến đường? Lựa chọn cổng tự động có thể làm những điều dường như không thể đoán trước.

Tôi không sử dụng RedHat hoặc CentOS, nhưng hãy thử xem bất kỳ tập lệnh nào được gọi khi bạn thực hiện service network restart. Vì mạng của bạn trở lại bình thường khi có điều gì đó trong tập lệnh đó xảy ra, nó có thể giúp thu hẹp nó.

Hừm.

Có lẽ một sự thay đổi tình cờ cho iptables? Nó có thể giải thích cả lý do tại sao nó không thể truy cập và tại sao không có gì lạ trong nhật ký (có lẽ bạn không đăng nhập iptables. Bạn có sao không?)