Skocz do zawartości
Zaloguj się, aby obserwować  
Be4ver

Kontener OpenVZ niewidoczny z zewnątrz

Polecane posty

Witam,

zainstalowałem paczkę OpenVZ na Debian 6 (amd64), zaraz po tym utworzyłem pierwszy kontener z przygotowanym przeze mnie obrazem Debiana6 (również amd64). Kontenerowi nadałem IP zewnętrzne i wszystko było dobrze. Następnie usunąłem kontener. Zainstalowałem OpenVZ wraz z Dnsmasq.

 

Tutaj zaczynają się schody... po utworzeniu kontenera i nadaniu mu zewnętrznego IP, kontener jest niewidoczny na zewnątrz... dopiero gdy podłączę się do VPN'a, mogę pingować go i łączyć się z nim.

 

Co z takim kwiatkiem zrobić? Przypuszczam, że winne temu mogą być wpisy iptables do rc.local.

 

Nieco informacji na temat CT0 i kontenera:

 

CT0/etc/rc.local

iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -s 10.8.0.0/24 -j ACCEPT
iptables -A FORWARD -j REJECT
iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

/etc/init.d/dnsmasq restart

exit 0

 

CT0: route -n

Kernel IP routing table
Destination		 Gateway		   Genmask			  Flags Metric Ref	Use  Iface
88.198.192.XX   0.0.0.0			  255.255.255.255  UH	   0	  0		0	  venet0
10.8.0.2              0.0.0.0             255.255.255.255  UH	   0	  0		0	  tun0
88.198.92.YY    88.198.92.ZZ    255.255.255.240  UG	   0	  0		0	  eth0
88.198.92.YY    0.0.0.0               255.255.255.240  U		  0	  0		0	  eth0
10.8.0.0			  10.8.0.2           255.255.255.0	  UG	   0	  0		0	  tun0
0.0.0.0				88.198.92.ZZ  0.0.0.0				  UG	   0	  0		0	  eth0

 

Nie podoba mi się 192.0.2.1 w poniższym route'sie.

Kontener CT0: route -n:


Destination	 Gateway		 Genmask			  Flags Metric Ref	Use   Iface
192.0.2.1		0.0.0.0			255.255.255.255  UH		 0	  0		0	 venet0
0.0.0.0			192.0.2.1		0.0.0.0				  UG		 0	  0		0	 venet0

 

/etc/resolve.conf (CT0 i kontener):


nameserver 213.133.99.99
nameserver 213.133.100.100
nameserver 213.133.98.98

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

W ogóle nie powinieneś grzebać w routingu. Wywal te reguły, ustaw w vz.conf

NEIGHBOUR_DEVS=all

Zrestartuj vz i sprawdź.

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Skoro na maszynie matce (bo CT0 wyglada wlasnie na hypervisor) tniesz caly FORWARDING, to jak niby to ma ci dzialac? Golab pocztowy ma te pakiety doslac do kontenera?

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

W ogóle nie powinieneś grzebać w routingu. Wywal te reguły, ustaw w vz.conf

NEIGHBOUR_DEVS=all

Zrestartuj vz i sprawdź.

Dzięki, pomogło.

 

Skoro na maszynie matce (bo CT0 wyglada wlasnie na hypervisor) tniesz caly FORWARDING, to jak niby to ma ci dzialac? Golab pocztowy ma te pakiety doslac do kontenera?

Tak, CT0 to matka.

Faktycznie, po nocy szukałem bardziej pod kątem DROP'ów... Stąd ten problem...

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Dla potomnych:

Ostatecznie skończyło się na tym, że po wprowadzeniu zmian, wszystko ładnie łączyło się i działało, poza ruchem via VPN. Nie wczytywały się strony, komunikatory nie działały etc.

 

Przeanalizowałem logi i route - okazało się, że cały ruch zostaje na serwerze i nie chce iść dalej.

Problem rozwiązała linijka poniżej dodana do pliku /etc/rc.local na CT0 zaraz przez "exit 0":

 

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Udostępnij ten post


Link to postu
Udostępnij na innych stronach

Bądź aktywny! Zaloguj się lub utwórz konto

Tylko zarejestrowani użytkownicy mogą komentować zawartość tej strony

Utwórz konto

Zarejestruj nowe konto, to proste!

Zarejestruj nowe konto

Zaloguj się

Posiadasz własne konto? Użyj go!

Zaloguj się

Zaloguj się, aby obserwować  

×