Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Mam sobie maszynę z IP x.x.55.3 i przypisaną do tej maszyny klasę IP x.x.127.80/29, w jaki sposób ustawić na VM sieć?
Na głównej maszynie ustawiłem
iptables -t nat -A POSTROUTING -s x.x.127.80/29 -j MASQUERADE iptables -A FORWARD -s x.x.127.80/29 -j ACCEPT
Na VM ustawilem IP x.x.127.81 ale nie mogę ustawić routingu na x.x.55.3.
br0 mam skonfigurowany poprawnie
Offline
Szklanej kuli to tu nie ma nikt, wszystkie się stłukły, a wróżki zwiały na wyspy.
Napisz też lepiej, jaki OS, pokaż cały konfig sieci i firewalla.
Skrócony opis tych maszynek wirtualnych też nie zawadzi przy okazji.
Na VM ustawilem IP x.x.127.81 ale nie mogę ustawić routingu na x.x.55.3.[/quote]
W jakich okolicznościach tego routingu nie łapie? Przy ifconfig, ip route add czy plik konfiguracyjny systemowy albo VM.
Jakichś utrudniaczy typu libvirt/virsh/virtmanager używasz?Ostatnio edytowany przez Jacekalex (2013-12-29 23:26:49)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
Wygląda to tak:
Mam serwer z ip x.x.55.3 i na nim KVM i bridge. Do serwera mam przypisana klasę x.x.127.80/29 wiec na głównej maszynie dodałem x.x.127.81/29 do br0 i wklepałem
iptables -t nat -A POSTROUTING -s X.X.127.82/32 -j MASQUERADE iptables -A FORWARD -s X.X.127.82/32 -j ACCEPT
a na maszynie wirtualnej dodałem X.X.127.82 a jako gateway podałem X.X.127.81
Po odpaleniu, X.X.127.82 odpowiada mi na 1 ping i koniec. Nie mam z tą maszyną połączenia z zewnątrz, natomiast na niej internet śmiga, mogę pingować etc i nie wiem gdzie jest problem.
echo 1 > /proc/sys/net/ipv4/ip_forward
tez jest
br0:
br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP link/ether 40:61:86:be:83:b8 brd ff:ff:ff:ff:ff:ff inet X.X.55.3/26 brd 178.63.55.63 scope global br0 inet X.X.127.81/29 scope global br0 inet6 fe80::4261:86ff:febe:83b8/64 scope link valid_lft forever preferred_lft forever
Ostatnio edytowany przez lewyx84 (2013-12-29 23:14:38)
Offline
Na VM ustawilem IP x.x.127.81 ale nie mogę ustawić routingu na x.x.55.3.[/quote]
I nie powinien przyjąć, bo routing się ustawia wewnątrz wydzielonego segmentu sieci, a nie losuje w totolotka.
A to jest twoja sieć dla VM:Kod:
ipcalc *.*.127.80/29 Address: *.*.127.80 10110010.11010010.01111111.01010 000 Netmask: 255.255.255.248 = 29 11111111.11111111.11111111.11111 000 Wildcard: 0.0.0.7 00000000.00000000.00000000.00000 111 => Network: *.*.127.80/29 10110010.11010010.01111111.01010 000 HostMin: *.*.127.81 10110010.11010010.01111111.01010 001 HostMax: *.*.127.86 10110010.11010010.01111111.01010 110 Broadcast: *.*.127.87 10110010.11010010.01111111.01010 111 Hosts/Net: 6 Class BZ tego wynika, że adres routera musi się mieścić w klasie adresowej *.*.127.80/29, ustaw routing przez *.*.127.81 - wtedy powinno działać,
ale na VM będziesz miał 5 wolnych IP.
Z każdej podsieci wydzielonej routerem odpadają 3 adresy - adres sieci, routera i broadcast.
A router dla VM robisz na mostku w systemie.
Przy okazji, jeśli VM-y mają publiczne IP, to do czego, i dlaczego ładujesz maskaradę na FW?
Przyjemnej lektury:
http://pl.wikipedia.org/wiki/IPv4
http://pl.wikipedia.org/wiki/Router
Pozdrów ode mnie protokół IPv6 :D
Dosiego roku ;)
W demokracji każdy naród ma taką władzę, na jaką zasługuje ;)
Si vis pacem para bellum ;) | Pozdrawiam :)
Offline
Napisałem, że ustawiłem routing na .81 i nie działa :-)
Odpowiedź jest na 1 ping i na tym koniec ;)
Offline
Na pingi z zewnątrz (z internetu) adresowane na .81 przychodzą odpowiedzi?
Pokaż
ip route show
z serwera.
Ostatnio edytowany przez Jacekalex (2013-12-29 23:56:56)
Offline
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
Offline
Pingi na serwerze z localhosta, czy z internetu.
Fajnie byłoby sprawdzić i tu i tu.
X.X.127.80/29 dev br0 proto kernel scope link src X.X.127.81
Ten wpis wygląda na prawidłowy, więc albo coś nie funguje na mostku, albo FW coś blokuje.
W FW kluczowa jest kolejność reguł, i to, czy dana reguła kończy lub nie przetwarzanie pakietu.
Jak zapinasz kartę VM do mostka, i przede wszystkim jakim poleceniem podnosisz maszynę KVM?
Czym ją konfigurowałeś.
Pytam, bo mam w domu takie maszynki:
qemu-kvm -hda /media/box/FreeBSD9.img -m 1024 -net nic,macaddr=00:1d:82:ac:3f:65 -net tap,ifname=tap1,script=no,downscript=no -alt-grab -name FreeBSD9 -boot d
qemu-kvm -hda /media/box/Debian.img -m 512 -net nic,macaddr=00:1d:92:ab:3f:78 -net tap,ifname=tap0,script=no,downscript=no -nographic -alt-grab -name Debian -boot d
I chodzą, net mają przez maskaradę, dostają adresy z klasy 10.0.5.x, lecą przez mostek br0 do netu (ppp0).
Sytuacja trochę podobna jak i Ciebie, a jednak działa.
Mostek tworzy się automatycznie takim skryptem:
#!/bin/sh brctl delbr br0 2>/dev/null tunctl -u {pacjent} -t tap0 2>/dev/null tunctl -u {pacjent} -t tap1 2>/dev/null ip link tap0 up 2>/dev/null ifconfig tap0 promisc up 2>/dev/null ip link tap1 up 2>/dev/null ifconfig tap1 promisc up >/dev/null brctl addbr br0 2>/dev/null brctl addif br0 tap0 2>/dev/null brctl addif br0 tap1 2>/dev/null ifconfig br0 10.0.5.1 netmask 255.255.255.0 2>/dev/null ifconfig br0 up 2>/dev/null
Ciekawe, jak wyciągnąć podobne informacje z Twojego serwera? :D
Ostatnio edytowany przez Jacekalex (2013-12-30 01:38:46)
Offline
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 :)
Offline
Przy takim FW maszynka z zewnątrz nie będzie widoczna, bo jest schowana za NATem z maskaradą.
Jeśli ta maszynka ma publiczny IP, i ma być widoczna w necie, to wywal maskaradę, i zrób routing jak trzeba.
Tak, żeby wchodząc na adres *.*.127.82 można było z netu trafić na VM.
Bo chyba o to tutaj chodzi.
I moim zdaniem ta maskarada i FORWARD tu mieszają.
Bo jak inaczej rozumiesz te regułki:
iptables -A FORWARD -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
I dlaczego, jeżeli adres VM *.*.127.82 ma być widoczny w necie, to nie ma tutaj żadnej reguły, która by pozwalała na to, aby połączenie z netu na adres *.*.127.82 trafiło bezproblemowo do VM, który ma ten adres?
A jeśli Twoim zdaniem jest, to pokaż, która?
Jak twoim zdaniem te reguły w tej chwili działają, i czy na pewno tak, jak Twoim zdaniem powinny?
Bo ja tu podejrzewam poważny błąd w sztuce.
Ostatnio edytowany przez Jacekalex (2013-12-30 14:36:42)
Offline
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ć.
Offline
Wyczyściłem reguły i wklepałem:
iptables -t filter -A FORWARD -s X.X.127.80/29 -d 0/0 -j ACCEPT iptables -t filter -A FORWARD -s 0/0 -d X.X.127.80/29 -j ACCEPT
odpowiedziało mi na 10 pingów i padło
Ostatnio edytowany przez lewyx84 (2013-12-30 23:45:55)
Offline
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.
Offline
Jest wystawione ssh i działa tak samo jak pingi. Chwila, bądź kilka chwil i lipa.
To nie ovh :-)
Pisałem z supportem i odpowiedzieli mi, że nie muszą nigdzie dopisywać virtualnego MACa
Offline
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?
Offline
Serwer stoi w hetzner.
Przed chwilą udało mi się kuźwa zrobić, że pingi non stop szły, nic nie przerywało.
Zretartowałem server, żeby zobaczyc czy po rebocie będzie działało i niet...
Może zaczniemy od początku co?
Na głównej maszynie wystarczy
iptables -t filter -A FORWARD -s X.X.127.80/29 -d 0/0 -j ACCEPT iptables -t filter -A FORWARD -s 0/0 -d X.X.127.80/29 -j ACCEPT
+
echo 1 > /proc/sys/net/ipv4/ip_forward
tak?
Offline
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.
Offline
Teraz się w ogóle coś porąbało, bo VM nie widzi nawet gateway ( X.X.127.81 ) i nie ma netu
Offline
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)
Offline
iptables powinno być następujące:
iptables -t filter -A FORWARD -s X.X.127.82/32 -d 0/0 -j ACCEPT
iptables -t filter -A FORWARD -s 0/0 -d X.X.127.82/32 -j ACCEPT
oprócz tego pomogło ( u mnie )
ip link set br0 address (taki sam jak eth0 ) mimo, że w ifconfig wyglądał na identyczny.
Pzdr
Pomyślności w Nowym Roku :-)
Offline
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)
Offline
Po skonfigurowaniu br0, iface eth0 nie posiada żadnego adresu :)
Wszystkie IP podnoszone są na br0 :)
Zastanawia mnie tylko jeszcze jedna rzecz, mianowicie, dlaczego po skasowaniu wszystkich reguł i dodaniu ich na nowo, już to nie działa i muszę restartować serwer :D
Ostatnio edytowany przez lewyx84 (2013-12-31 14:44:14)
Offline
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)
Offline
Time (s) | Query |
---|---|
0.00010 | SET CHARSET latin2 |
0.00004 | SET NAMES latin2 |
0.00078 | SELECT u.*, g.*, o.logged FROM punbb_users AS u INNER JOIN punbb_groups AS g ON u.group_id=g.g_id LEFT JOIN punbb_online AS o ON o.ident='3.144.92.165' WHERE u.id=1 |
0.00062 | REPLACE INTO punbb_online (user_id, ident, logged) VALUES(1, '3.144.92.165', 1732855468) |
0.00054 | SELECT * FROM punbb_online WHERE logged<1732855168 |
0.00043 | SELECT topic_id FROM punbb_posts WHERE id=249804 |
0.00006 | SELECT id FROM punbb_posts WHERE topic_id=24908 ORDER BY posted |
0.00046 | SELECT t.subject, t.closed, t.num_replies, t.sticky, f.id AS forum_id, f.forum_name, f.moderators, fp.post_replies, 0 FROM punbb_topics AS t INNER JOIN punbb_forums AS f ON f.id=t.forum_id LEFT JOIN punbb_forum_perms AS fp ON (fp.forum_id=f.id AND fp.group_id=3) WHERE (fp.read_forum IS NULL OR fp.read_forum=1) AND t.id=24908 AND t.moved_to IS NULL |
0.00005 | SELECT search_for, replace_with FROM punbb_censoring |
0.00119 | SELECT u.email, u.title, u.url, u.location, u.use_avatar, u.signature, u.email_setting, u.num_posts, u.registered, u.admin_note, p.id, p.poster AS username, p.poster_id, p.poster_ip, p.poster_email, p.message, p.hide_smilies, p.posted, p.edited, p.edited_by, g.g_id, g.g_user_title, o.user_id AS is_online FROM punbb_posts AS p INNER JOIN punbb_users AS u ON u.id=p.poster_id INNER JOIN punbb_groups AS g ON g.g_id=u.group_id LEFT JOIN punbb_online AS o ON (o.user_id=u.id AND o.user_id!=1 AND o.idle=0) WHERE p.topic_id=24908 ORDER BY p.id LIMIT 0,25 |
0.00088 | UPDATE punbb_topics SET num_views=num_views+1 WHERE id=24908 |
Total query time: 0.00515 s |