Otwarte gniazdo PING icmp: Operacja niedozwolona w vserver

14

Używam środowiska vserver z kilkoma maszynami wirtualnymi. Pojedyncza maszyna wirtualna ma następujący problem:

$ ping 8.8.8.8
ping: icmp open socket: Operation not permitted

$ ls -l $(which ping)
-rwsr-xr-x 1 root root 30736 2007-01-31 00:10 /bin/ping

$ whoami
root

$ mount
/dev/hdv1 on / type ufs (defaults)
none on /proc type proc (0)
none on /tmp type tmpfs (size=16m,mode=1777)
none on /dev/pts type devpts (gid=5,mode=620)

$ uname -a
Linux v-web1 2.6.27.55-vs2.3.0.36.9 #1 SMP Tue Apr 28 11:35:00 CEST 2015 i686 GNU/Linux

Zauważ, że na maszynie hosta, jak również na wszystkich innych hostach VM, Ping działa dobrze.

Czy ktoś ma jakiś pomysł, aby mi pomóc?

rexkogitans
źródło
Czy /bin/pingustawiony jest na innych komputerach? Czy protokół TCP / IP jest poprawnie skonfigurowany na tej maszynie wirtualnej? Czy inne rzeczy działają jak DNS, traceroute, HTTP?
David Schwartz
2
Czy próbowałeś ponownie zainstalować ping iputils?
Nabil Bourenane
Przydatna może być inna informacja: Jest to bardzo produktywna maszyna z uruchomionym Apache z szybkością około 5 do 7 dostępów na sekundę - więc nie mam pojęcia o modyfikacji konfiguracji sieci. Ostatniej nocy został przeniesiony na nowy sprzęt i od tego czasu Munin pokazuje, że Ping nie działa.
rexkogitans

Odpowiedzi:

12

Wersja TL; DR: zainstaluj ponownie iputils-ping

Widziałem online, gdzie sugerowano użycie

chmod u+s $( which ping );

Pozwoli to jednak użytkownikowi zmienić napięcie wstępne i zalanie. Może to spowodować, że UŻYTKOWNIK będzie w stanie odmówić usługi na komputerze lokalnym lub innym komputerze lub sieci.

Próbowałem, co sugeruje @ nabil-bourenane , ponowna instalacja, iputils-pingktóra rozwiązała problem i nie ma ustawionego bitu SUID.

username@server:~$ ls -l $( which ping );
-rwxr-xr-x 1 root root 44104 Nov  8  2014 /bin/ping

Jeśli ustawiony jest bit SUID, będzie wyglądał

username@server:~$ ls -l $( which ping );
-rwsr-xr-x 1 root root 44104 Nov  8  2014 /bin/ping
Linx
źródło
Jeśli jesteś już rootem, pliki binarne katalogu głównego SUID niewiele się zmienią.
Falcon Momot,
@ FalconMomot, załączyłem rozwiązanie.
rexkogitans
Ponowna instalacja iputils (ta sama wersja przed / po) działała dla mnie na centos7. Wcześniej getcap / bin / ping nie pokazywał żadnych możliwości. Po ponownej instalacji, getcap /bin/pingwrócił: /bin/ping = cap_net_admin,cap_net_raw+p. Teraz pytanie brzmi: dlaczego straciło możliwości. rpm --verify iputilspokazał, że ping, arping i clockdiff pokazały, że ustawienia limitów uległy zmianie (przed ponowną instalacją).
Juan
W moim przypadku mogła utracić możliwości plików po przywróceniu z obrazu zrzutu. Zobacz także unix.com/unix-for-advanced-and-expert-users/… . W takim przypadku użyli smoły. W moim przypadku miałem nadzieję, że zrzut / przywrócenie zachowa wszystkie te atrybuty pliku (attrs, możliwości, acls itp.). Dziwię się, że tak się nie stało, więc muszę sprawdzić, czy mogę to odtworzyć (a potem może zarejestrować błąd).
Juan
1

Rozwiązaniem jest takie ustawienie Linux System Capabilites, aby zezwalało na surowe gniazdo na hoście.

Ponieważ jest to problem specyficzny dla serwera v, rozwiązaniem jest utworzenie pliku o pojedynczej linii o nazwie /etc/vservers/VMNAME/bcapabilities:

NET_RAW

i zrestartuj VM.

rexkogitans
źródło
1
„A jak to osiągasz?” przydałby się jako kompletna odpowiedź.
ILMostro_7,
Po 4 latach zmieniłem przyjętą odpowiedź na moją, ponieważ NAPRAWDĘ ODPOWIADA NA PYTANIE. Jest to problem z serwerem v i nie ma nic wspólnego z trybem pliku wykonywalnego polecenia ping.
rexkogitans
1

Przepraszam, nie mogę komentować. Ten problem uderzył mnie po rozpakowaniu archiwum działającego systemu przy minimalnej instalacji.

Wszystkie powyższe odpowiedzi działają. Ale ten zaproponowany przez @Nabil Bourenane i @Linx jest preferowany ze względów bezpieczeństwa. Aby odpowiedzieć na komentarz @ rexkogitans, tutaj cytuję z iputils-ping.postinst (/ var / lib / dpkg / info / ...)

if command -v setcap > /dev/null; then
    if setcap cap_net_raw+ep /bin/ping; then
        chmod u-s /bin/ping
    else
        echo "Setcap failed on /bin/ping, falling back to setuid" >&2
        chmod u+s /bin/ping
    fi
else
    echo "Setcap is not installed, falling back to setuid" >&2
    chmod u+s /bin/ping
fi

co w zasadzie mówi podczas konfigurowania iputils-ping, najpierw spróbuj setcap, a jeśli to się nie powiedzie, użyj chmod u + s. Dlatego przeinstalowanie działa iputils-ping.

rlf
źródło
1
Więc to zadziała: setcap cap_net_raw + ep / bin / ping
rlf
To nie był mój komentarz, ale odpowiedź na moje własne pytanie. Problemu nie można rozwiązać z wnętrza kontenera, więc cokolwiek robi hak po instalacji, nie ma sensu.
rexkogitans
Rzeczywiście, setcap cap_net_raw+p $(which ping)jak root to naprawia. Dokładne wyjaśnienie tego postu na blogu: Linux Capabilities and Ping
mivk