Изпечатай

[Ali Nebi]

Здравейте,

бих искал да попитам дали може да ми дадете някакви идеи как мога да разреша следния проблем.

Подкарах на CentOS5, под хеn AsteriskNow, и конфигурирах мрежата, както трябва. Имаме 2 публични адреса, единият е за DomU. Проблемът е следният, когато се опитам да достъпя астерискноу, не мога, дори нямам пинг. Направих тестове с нмап и ми искарва, че портовете са филтрирани към това ip. А виждам, че на реалната машина се добавят тези правила в iptables:

ACCEPT     all  --  asterisknow.xxx.xx     anywhere            PHYSDEV match --physdev-in vif19.0
ACCEPT     udp  --  anywhere             anywhere            PHYSDEV match --physdev-in vif19.0 udp spt:bootpc dpt:bootps

Дори и така, пак не ме допуска. Как бих могъл да реша този проблем?

Мерси предварително!

[gat3way]

На dom0 имаш ли вдигнат bridge? Ако нямаш бриджинг между физически интерфейс и "виртуалният", който се ползва от domU, guest домейна няма да е достъпен отвън. Алтернативата е да правиш port forwarding например, но е куца по принцип, особено що се отнася до asterisk и някакви дивни от сорта. А иначе не знам защо излизат като филтрирани портовете, според мен трябва да връща ICMP destination unreachable или нещо от сорта.

[Ali Nebi]

Ами ползвам network-route i vif-route, и за астериск-а съм задал статично едно от публичните ip-та. Също така създадох един файл route-eth0, където добавих ред:

default dom0_public_ip_address dev eth0

По този начин за астериск гейтуеа ще бъде другото публично ip. Това го правя заради спецификата на мрежата на провайдера. Мисля, че там някъде куца и затова дава, че е филтриран порта, както и че пинга не връща нищо. Същата конфигурация я провбах на един от комповете в офиса с частна мрежа, и работеше.

Не ползвам бридж, защото рутерът на провайдера ни изключва от мрежата заради възможен mac spoofing най-вероятно

[gat3way]

Хм, ами всъщност и така предполагам може (IP forwarding-a трябва да работи и между "виртуални" интерфейси). Но в този случай на посления хоп на твоят доставчик преди твоята машина трябва да има един статичен маршрут, който да казва че за вторият адрес трябва да се минава през първият, нещо от сорта на:

route add <ip2> gw <ip1>

в противен случай пакетите, които са предназначени за виртуалната машина няма да отиват там.

[Ali Nebi]

На друг сървър с Ubuntu и направена същатата конфигурация работи '> А при мен на Centos неще, ще поразгледам още да видя как да го направя.

Интересното е, че всяко публично ip е с маска 255.255.255.255, т.е. broadcast-a е само това ip.

IP-тата започва с 8X.xxx.xxx.xx, gateway-на провайдера е 10.255.xxx.xxx

[gat3way]

Хм, а дали става ако направиш следното?

echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce
echo 0 > /proc/sys/net/ipv4/conf/eth0/arp_announce

Което не е много в реда на нещата, но би следвало да оправи нещата с липсата на статичен маршрут при доставчика (предполагам) ?

Това на дом0 разбира се '>

[Ali Nebi]

М нем, не помогна.

Същата ситуация е.

П.С.
Мисля, че разбрах къде е проблема, може и да не е '>

Когато xen създава vif на този сървър той изглежда така:

vif28.0   Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          inet addr:87.106.XXX.XXX  Bcast:87.106.XXX.XXX  Mask:255.255.255.255
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0  TX bytes:0 (0.0

А на други сървър, където работи изглежда така:

vif28.0   Link encap:Ethernet  HWaddr FE:FF:FF:FF:FF:FF  
          inet addr:87.106.XXX.XXX  Bcast:87.255.255.255  Mask:255.255.255.255
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:32
          RX bytes:0 (0.0  TX bytes:0 (0.0

Възможно ли е тази разлика в broadcas-та да е реално проблемът?


П.С. Това не реши проблема, както и предполагах '>

[bubu]

Ако наистина мислиш, че е от мрежовите настройки защо не пробваш да ги смениш с ifconfig и не видиш дали няма да се оправи проблема ?

[Ali Nebi]

Ами аз не ги сменям с ifconfig, а коригирам директно файла, където записва настройките и след това пускам виртуалната машина на ново, защото нямам достъп по ssh до DomU. Въпросът е, че пътят по който се пращат пакетите, някъде не е правилен, нещо не се получава както трява.

Насоките на gat3way бяха точно към това нещо.

П.С.

Реших проблема, явно route-eth0 файла не е работил както трябва.

Премахнах го и довабих две правила в rc.local за да задам default gw:

route add 87.xxx.xxx.xxx dev eth0
route add default gw 87.xxx.xxx.xxx

Това реши проблема и сега достъпвам domU.
Сега имам проблеми с dns-те на DomU, но това ще го оправим '>

Мерси на всички '>