Forum Debian Users Gang

Napisałem, że ustawiłem routing na .81 i nie działa :-)
Odpowiedź jest na 1 ping i na tym koniec ;)

default via X.X.55.1 dev br0
X.X.55.0/26 dev br0  proto kernel  scope link  src X.X.55.3
X.X.127.80/29 dev br0  proto kernel  scope link  src X.X.127.81

na .81 przychodzą pingi, na 82 tylko pierwszy

Już Ci szanowny kolego mówię :)
Maszyna uruchamiana jest za pomocą

kvm \
-netdev tap,id=net0 -device e1000,netdev=net0,mac=DE:AD:BE:EF:00:82 \
-drive file=hda,if=virtio,index=0,cache=none \
-drive file=hdb,if=virtio,index=1,cache=none \
-boot d \
-cpu core2duo \
-smp 1 \
-m 5G \
-vga std \
-vnc :0&

I teraz, jeśli zrobię połączenie na IP z LANu ( 10.0.0.0/24 ) i udostępnie neta przez maskaradę to owszem, wszystko działa prawidłowo i net jest, w poprzednim DC miałem dodatkowe adresy IP ( failover ) i na VM również działały ( gateway był w tej samej sieci ) a tu jeśli mam IP z innej klasy to duuupa ;)

Jeśli chodzi o FW to wygląda on tak :

# wlaczenie w kernelu forwardowania
echo 1 > /proc/sys/net/ipv4/ip_forward

# czyszczenie starych regul
iptables -F
iptables -X
iptables -t nat -X
iptables -t nat -F
iptables -t mangle -F
iptables -t mangle -X

# ustawienie domyslnej polityki
iptables -P INPUT ACCEPT
iptables -P FORWARD ACCEPT
iptables -P OUTPUT ACCEPT

# utrzymanie polaczen nawiazanych
iptables -A INPUT -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -A FORWARD -j ACCEPT -m state --state ESTABLISHED,RELATED
iptables -A OUTPUT -j ACCEPT -m state --state ESTABLISHED,RELATED


iptables -t nat -A POSTROUTING -s 178.63.127.80/29 -j MASQUERADE
iptables -A FORWARD -s 178.63.127.80/29 -j ACCEPT

Po odpaleniu maszyna jest widoczna z :
1) zewnątrz - jak jej sie chce, minute, dwie, 10 minut
2) z serwera na którym jest odpalana - cały czas

Po zalogowaniu się na VM via VNC internet działa cały czas, mogę pingować z virtualki co mi sie podoba.

Jak mniemam chodzi Ci o skrypt /etc/qemu-ifup a wygląda on w ten sposób:

#!/bin/sh

echo "Executing /etc/qemu-ifup"
echo "Bringing up $1 for bridged mode..."
sudo /sbin/ifconfig $1 up
echo "Adding $1 to br0..."
sudo /usr/sbin/brctl addif br0 $1

Pzdr :)

Ale maszyna jest widoczna z zewnątrz. Na chwile, dłuższą lub krótszą.
Nie jestem specjalistą w iptables, więc jak możesz, to podrzuć jak to mniej więcej powinno wyglądać.

10 pingów i padło?

A nie załapałeś się na zabezpieczenia OVH?
Tam mają limit z jednego IP - maks 32 kbit/s ICMP.
To są zabezpieczenia Anty-DDOS, które "wymodliła" większość wynajmujących dedyki, zwłaszcza serwery z grami obrywają co chwila.
Jest też limit na UDP, ale ten, to chyba 5 albo 50 Mbit z jednego IP.

Wystaw na VM jakąś usługę typu Apache czy Lightppd i zobacz, czy ją widać w necie.

A co to w ogóle za serwerownia?

W ogóle dziwna sprawa, jak jest komunikacja i połączenie, to nie czaję, dlaczego zdycha po kilku minutach.

Może zapuść iperfa miedzy kompem w domu a tym serwerem, żeby zobaczyć, co się na linii dzieje.

Sytuacja, w której jest nawiązane połączenie, oznacza, ze routing poszedł prawidłowo, FW nie zablokował, ale coś wykańcza transfer sieciowy dla tego połączenia, jakby był limit ilości danych, jakie przejdą danym połączeniem.

Rozumiem, że z maszyną główną nie ma takich problemów, tylko z VM?

Możliwe.

Moim zdaniem coś dziwnego się na sieci dzieje, albo na tym serwerze, albo gdzieś po drodze.

Zapuść iperfa między chałupą ia serwerem, niech sobie powisi godzinkę ze stałą prędkością raz z VM raz z maszyną główną, i będzie mniej więcej jasne, co jest grane, czy winny serwer, czy coś innego na sieci.

Po prostu w tej chwili, to jest takie z dupy wróżenie, można przekopać wszystkie logi, można puścić FW w trybie debug modułem TRACE, można próbować na innym kernelu, kombinować opcjami w sysctl, ale jak nie wiadomo, gdzie dokładnie szukać, to jest dość ciężka sprawa.
Trochę za dużo elementów jest do sprawdzenia.

A czy tam na tym serwerze jakieś krasnoludki urzędują?

Bo samo, coś porąbało, to możesz teściowej opowiadać.

Tam się coś sypie, i to jest albo wina kernela i ustawień sieciowych, które siedzą w sysctl, albo coś dziwnego siedzi w którejś tablicy FW, albo szaleje sterownik,
albo ewentualnie ten serwer właśnie obrywa jakimś atakiem, o czym każdy normalny admin powinien wiedzieć, bo mogłeś adresy IP dostać po jakimś mocno ostrzeliwanym serwerze.

Ale żeby to wiedzieć, to trzeba admina, a nie kalesony, czy gościa w stylu "coś się porąbało".

Jesteś adminem, to  miej logi i patrzaj w logi, są programy monitorujące i diagnostyczne , jest tysiąc różnych możliwości.

Nie ma natomiast wróżki i szklanej kuli, żeby wiedzieć, co się stało, kiedy "coś się porąbało".

Ostatnio edytowany przez Jacekalex (2013-12-31 01:59:19)

Jeśli zamiast eth0 wystawiasz br0, to do eth0 i innych kart podpinanych do mostka w ogóle nie daje się adresów IP, po prostu je zapinasz do br0, i adresy przypisujesz do br0.

Jeśli eth0 miała własny adres, a była wpięta do br0, to w ogóle się dziwię,
że to czasami jakośtam działało.
Jeśli natomiast br0 i eth0 mają ten sam adres, to system widzi dwa interfejsy z tym samym adresem, i się robi burdel w routingu.

A pisałeś wyżej, że mostek jest "na pewno prawidłowy" ..... :D

Dosiego Roku!
;-)

Ostatnio edytowany przez Jacekalex (2013-12-31 13:28:44)

Widocznie pliki konfiguracyjne masz prawidłowo, dlatego po starcie działa,
ale jak z palca coś zmieniasz, to ustawienia diabli biorą.

W ogóle ja rozumiem, że system potrzebuje pliki konfiguracyjne dla miłośników takowych ;), ale sam wolę sobie naskrobać skrypta, który ustawi wszystko, 
co się da, automatycznie, jak się potem coś zętoli,
to jedno polecenie w konsoli  i jest prawidłowo.

W ten sposób wszędzie i na każdym systemie wszytko mi działa, i nawet nie muszę w 5 sekund po zalogowaniu znać składni plików w Centos, czy SUSE,
bo konsola jest we wszystkich Linuxach taka sama, a w *BSD też jest bardzo podobna (interfejsy mają inne nazwy domyślne ;) ).

Ostatnio edytowany przez Jacekalex (2013-12-31 15:11:40)