Ping'lere cevap vermek için hangi Linux süreci sorumlu?

Bazen ping yapamayacağınız bir noktaya kadar kilitlenen Linux tabanlı bir işlem denetleyicisine sahibim (yani ping yapabiliyorum, daha sonra ağ ayarlarında herhangi bir değişiklik yapmadan artık ping edilemez).

Merak ediyorum, ping'lere verilen cevaptan hangi süreç / sistem sorumludur? Görünüşe göre bu süreç çöküyor.

network-interface ping icmp

— Izzo
kaynak

Ping'lere cevap vermediğinde hala ssh edebilir misin? Yoksa mevcut SSH oturumları kilitlendi mi?

— Peter Cordes

@PeterCordes Tüm sistem kilitlenir ve yeniden başlatmaya zorlanana kadar temelde bir tuğladır.

— Izzo,

Tamam, normalde bir makinenin ping'lere cevap vermeyi kesmesinin tek yolu budur. Eğer pingler çalışmamaya başlarsa ama diğer şeyler çalışmaya devam ederse garip olur, çünkü ping kullanımı kullanıcı alanı hortumlanmış olsa ve disk G / Ç'deki her şey ölü bir diske veya NFS montajına veya her neyse engellenmiş olsa bile çalışır. Bir monitörü sisteminize bağlamayı deneyin ve kilitlendiğinde bir konsol mesajı olup olmadığına bakın. (Ve eğer sihirli SysRQ klavye sekanslarını bilgi boşaltmak ya da salt okunur bir şekilde yeniden kullanmak için kullanabilirseniz, diskleri + yeniden başlatmaya zorla senkronize edin.

— Peter Cordes

Sorunuz ilginç olsa da, ping sisteminizin problemlerinin kaynağı değil, dengesiz bir sistemin sonucudur. Neyin yanlış olduğunu anlamak için günlükleri kontrol edin.

— Pedro Lobito

@PedroLobito Ne özel olarak günlüğe kaydeder?

— Izzo

Yanıtlar:

Çekirdek ağ yığını, pingkomut tarafından gönderilen ICMP iletilerini işlemektedir .

Cevap alamazsanız, ağ sorunları veya filtreleme dışında ve ana bilgisayar tabanlı filtreleme / hız sınırlayıcı / siyah boşluk / etc. Bu, makinenin muhtemelen ICMP trafiğinden dolayı (ancak bu tür bir trafiğe aşırı yüklenmeye çalışmak zorunda değil), nadir olabilen ancak nadiren meydana gelebilecek (hatalı donanım vb.) çekirdeği çökmüş veya geçici olabilecek bir şey tarafından aşırı yüklendiği anlamına gelir. Bir sunucunun kullanım ömrünün başlangıcında işleri nasıl sürdürdüğünü görmek için iyi bir sınav olabilir). Daha sonra çekirdek çökmesi durumunda, günlük dosyalarında veya konsolda yeterli bilgiye sahip olmalısınız.

Ayrıca ping, bir servisin çevrimiçi olup olmadığını kontrol etmek için neredeyse her zaman yanlış bir araç olduğunu unutmayın. Çeşitli nedenlerden dolayı, ancak çoğunlukla, gerçek uygulama trafiğini taklit etmediğinden, tanımı gereği. Örneğin, bir web sunucusunun hala canlı olup olmadığını kontrol etmeniz gerekiyorsa, bunun yerine bir HTTP sorgusu yapmanız gerekir (TCP bağlantı noktası 80 veya 443), bir posta sunucusunu kontrol etmeniz gerekirse bir SMTP sorgusu (TCP bağlantı noktası 25) DNS sunucusu, UDP ve 53 numaralı bağlantı noktasına bir TCP sorgusu vb.

— Patrick Mevzek
kaynak

@Diğer uygulama servis testlerinin başarısız olması veya zaman aşımına uğraması nedeniyle gözlemlenen sonuç aynı olacaktır. pingSorun giderme konusunda çok fazla yanlış pozitif sonuç yarattığından, kullanma konusunda ders verme fırsatını hiç kaçırmamıştım , bu yüzden kullanıcıların ping'in ne yaptığını ve nasıl yanıltıcı sonuçlar verebileceğini tam olarak bilmediklerini başka bir şeye yapmaları gerektiğini düşünüyorum.

— Patrick Mevzek

Çoğu aşırı yükleme durumunda hala yanıt veren tek şey çekirdek tarafından yapılanlardır. Bu, bir makinenin ne kadar aşırı yüklendiğine bakılmaksızın genellikle ping'e yanıt vereceği anlamına gelir. Kapalı bir porta ulaşma girişimleri, TCP için RST ve UDP durumunda bir ICMP hatası ile cevap verecektir. Açık bir TCP portuna ulaşmak için yapılan ilk birkaç deneme el sıkışmayı tamamlayacaktır. Bir disk hatası hemen hemen aynı belirtilere neden olabilir.

— kasperd

@ kasperd ICMP isteklerine cevap vermediğini (çok) aşırı yüklenen sunucuları (özel olarak değiştirilenleri) gördüm. Ve elbette başka hiçbir şeye. Çekirdek çökmedi, disk g / Ç işleriyle meşguldü.

— Patrick Mevzek

@Nacht Yup. Bir ağ arayüzü bir HW cihazıdır; gibi onunla arayüz için bir çekirdek sürücüsü var. İkinci katman daha sonra genel yönetim / iletişim API'leri sağlar. (Bu ağ oluşturma için benzersiz değil: ses aygıtları için ALSA var, video çıkışları KMS API'sini kullanıyor, USB'de {U, E, X} HCI var, daha sonra usb_storage, usbhid, vb.) Ağ yönlendirme tabloları, güvenlik duvarı kuralları (iptables üzerinden) ), el sıkışma, paket düzeneği, yeniden iletimler vb. ICMP kendi başına bir protokoldür, yük taşımayan ve "yanıt ver veya ver" in ötesinde bir işlem yapmadan, çekirdek ICMP yanıtlarını minimum ek yük için doğrudan ele alır.

— FeRD

@Nacht: Bu gerçekten temel bilgisayar mimarisi ile ilgili değil; bu bir uygulama seçimi. Mikro çekirdekler bir işletim sistemi sürecinde ICMP'yi idare eder.

— MSalters

Ping'lere cevap vermekten sorumlu bir kullanıcı süreci yoktur. Ping, ICMP yankı paketlerini göndermek için yalnızca bir yardımcı programdır. Bunlar çekirdeğin ağ yığını tarafından alınır ve işlenir

— Outurnate
kaynak

Çekirdek kendisi (değil herhangi bir kullanıcı işlemi) gönderme karşı sorumludur ICMP yankı cevap cevap olarak mesajları ICMP'nin yankı isteği iletileri. Bu nedenle, bir ev sahibi ping'lere yanıt vermeyi keserse, genellikle aşağıdaki nedenlerden dolayı olabilir:

siz ve ev sahipliği yapan ağlayan arasındaki ağ bağlantısı kopmuş olabilir. Bunun nedeni tonlarca olabilir: kablolarda fiziksel hasar, kablosuz, bozuk rota tabloları durumunda gürültü, DDoS saldırısı altındasınız, aradaki sorunlu yönlendiriciler / anahtarlar vb. Bu durumda sorun gidermeye başlayabilirsiniz. kullanarak ethtool(8), iwconfig(8), route(8), ping(8)onun yönlendirici, tcpdump(8)hedef ana bilgisayarda vs..
Hedef ana bilgisayardaki güvenlik duvarı ayarı (veya siz ve hedef ana bilgisayar arasındaki herhangi bir yönlendirici / güvenlik duvarı) ping miktarını (veya trafik trafik miktarını) sınırlıyor olabilir. Ayrıca fail2ban(8), talep üzerine güvenlik duvarı gibi şeyler yapılması gibi araçlardan da kaynaklanıyor olabilir . iptables(8)Kontrol etmek için bakınız .
Hedef ana bilgisayarda yazılım / donanım arızası var. Hedef ana bilgisayardaki ağ çekirdeği modülünde OOPSed olabilir ve / veya kafası karışabilir veya hatta tüm çekirdek PANICked'e sahip olabilir. dmesg(8)Hedef ana bilgisayardaki veya fiziksel konsoldaki ekran çıktısı hakkında mesajlar görürsünüz (fiziksel erişim pratik değilse, seri konsolu olan başka bir makine yardımcı olabilir.) Eğer çekirdek OOPS / PANIC ise, daha iyi sürücülere sahip daha yeni bir çekirdek olabilir. Yardım, veya sistem kilitlerinin etrafında dolaşıp watchdog(8)sürücülerle yardımcı olabilirsiniz. Veya donanım parçalarını değiştirebilirsiniz.

— Matija Nalis
kaynak

İlgilenenler için, burada ICMP yankı isteklerini yerine getirmek için ilgili çekirdek kodu .

— Ruslan

ayrıca çok yüksek yükten de bahsetmelisin (özel cpu)

— Guilherme Bernal

@GuilhermeBernal hayır, aşırı derecede yüksek CPU kullanıcı yükü (binlerce) bile ICMP kaybına yol açmayacaktır (çünkü kullanıcı işlemleri çalışma şansı elde etmeden önce çekirdeğinde servis edilmektedir). Alt uç donanımı ile kombinasyon halinde aşırı yüksek ağ PPS hızlı paket kaybına neden olabilir, fakat bu DDoS "ağ bağlantısı" kategorisinde yer

— Matija Nalis