[need help] Проброс портов в виртуальную машину
В /proc/sys/net/ipv4/ip_forward 1?
....Кажется, твои настройки разрешают проброс туда и обратно только портов выше 1024, тогда как по условиям задачи требуется ниже.
Задача: пробросить часть портов (22, 80, 143)
....
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE tcp — 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
MASQUERADE udp — 192.168.122.0/24 !192.168.122.0/24 masq ports: 1024-65535
MASQUERADE all — 192.168.122.0/24 !192.168.122.0/24
UPD - хотя по идее последняя строчка может отрабатываться. Не уверен, отбросит ли ответные пакеты первое правило или просмотр правил пройдет до последнего, которое разрешит.
Без него было бы denied, а не timed out.
Эм... Это вроде в обратную сторону - чтобы у гостя доступ в инет был.
Что-то я в первом посте несколько напутал с направлением (спать, блин, надо больше, а не получается) .
На всякий случай уточняю: хочу сервисы, работающие в госте, сделать доступными для внешнего мира.
На всякий случай уточняю: хочу сервисы, работающие в госте, сделать доступными для внешнего мира.
из гостя пакеты роутятся на хост?
запусти пинг и потыкай tcpdump`ом во все места
запусти пинг и потыкай tcpdump`ом во все места
Эм... Это вроде в обратную сторону - чтобы у гостя доступ в инет был.
DNAT работает в паре с NAT. Первый отвечает за то чтобы пакет извне через хост был проброшен гостю. Ответный пакет гостя идет уже через NAT, потому что должен исходить с белым адресом хоста. Если же он через NAT не пойдет, то пакет так и останется с исходящим адресом гостя, а именно с серым 192.168.***.***. Вышестоящий роутер в результате его просто дропнет.
UPDATE:
в твоей инструкции между прочим так и указано:
iptables -t nat -A PREROUTING -d 192.168.0.11 -j DNAT --to-destination 192.168.122.99
iptables -t nat -A POSTROUTING -s 192.168.122.99 -j SNAT --to-source 192.168.0.11
In particular, list your iptables nat table:
sudo iptables -t nat -L
You should see:
...
Chain POSTROUTING (policy ACCEPT)
target prot opt source destination
MASQUERADE all — 192.168.122.0/24 !192.168.122.0/24
...
С хоста на гостя я могу зайти SSH-ем (на внутренний адрес в интернет гость имеет доступ (качает обновления).
DNAT работает в паре с NAT. Первый отвечает за то чтобы пакет извне через хост был проброшен гостю. Ответный пакет гостя идет уже через NAT, потому что должен исходить с белым адресом хоста. Если же он через NAT не пойдет, то пакет так и останется с исходящим адресом гостя, а именно с серым 192.168.***.***. Вышестоящий роутер в результате его просто дропнет.Если ответный пакет обратно пойдёт через этот сервер, то над ним будет произведено преобразование обратное DNAT, естественно. При чём здесь ещё какой-то NAT?
в твоей инструкции между прочим так и указано:Первое правило пробрасывает изначально входящие снаружи соединения. А второе для исходящих изнутри. NAT-правила являются stateful и работают после совпадения для пакетов проходящих в обе стороны. Если 2-е правило убрать, то снаружи можно будет подключиться к серверу, а вот изнутри сервер не сможет инициировать соединение.
iptables -t nat -A PREROUTING -d 192.168.0.11 -j DNAT --to-destination 192.168.122.99
iptables -t nat -A POSTROUTING -s 192.168.122.99 -j SNAT --to-source 192.168.0.11
точно, лоханулся, прав, нат тут не причем.
наметилась еще одна заковыка
Ты пробрасываешь внешний порт 8122 на внутренний 22, внешний 8443 на внутренний 443 и тд. То есть извне к гостю надо стучаться по адресу хоста и портам 8122, 8080, 8443 и тд, хотя на госте сервисы работают на 22, 80, 443 и тд. Надеюсь, я не выгляжу капитаном очевидность.
ssh host.ip.address -p 8122
наметилась еще одна заковыка
Задача: пробросить часть портов (22, 80, 143) с хоста на гостя.
#iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DNAT tcp — anywhere мойсервер tcp dpt:8122 to:192.168.122.209:22
DNAT tcp — anywhere мойсервер tcp dpt:http-alt to:192.168.122.209:80
DNAT tcp — anywhere мойсервер tcp dpt:8443 to:192.168.122.209:443
DNAT tcp — anywhere мойсервер tcp dpt:12320 to:192.168.122.209:12320
DNAT tcp — anywhere мойсервер tcp dpt:12321 to:192.168.122.209:12321
DNAT tcp — anywhere мойсервер tcp dpt:git to:192.168.122.209:9418
Ты пробрасываешь внешний порт 8122 на внутренний 22, внешний 8443 на внутренний 443 и тд. То есть извне к гостю надо стучаться по адресу хоста и портам 8122, 8080, 8443 и тд, хотя на госте сервисы работают на 22, 80, 443 и тд. Надеюсь, я не выгляжу капитаном очевидность.
ssh host.ip.address -p 8122
22, 80, 443 на хосте заняты другим проектом, поэтому сознательно были выбраны другие порты. Стучусь на правильный порт.
22, 80, 443 на хосте заняты другим проектом, поэтому сознательно были выбраны другие порты. Стучусь на правильный порт.Так tcpdump уже запустил или продолжаем телепатить?
В tcpdump-е тишина. Запускаю на хосте так:
Пытаюсь соединиться (с другой машины) так:
sudo tcpdump -i br0 -n -X 'port 8122'
Пытаюсь соединиться (с другой машины) так:
> ssh -vvvv xxx.xxx -p 8122
OpenSSH_5.8p1 Debian-1ubuntu3, OpenSSL 0.9.8o 01 Jun 2010
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to xxx.xxx [xxx.xxx.xxx.xxx] port 8122.
debug1: connect to address xxx.xxx.xxx.xxx port 8122: Connection timed out
ssh: connect to host xxx.xxx port 8122: Connection timed out
sudo tcpdump -i br0 -n -X 'port 8122'А у тебя bridge там ещё? Может с ним что-то не так?
мне тоже кажется что с бриджем не все в порядке, но не хотел оплошать в очередной раз 
br0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr: xxx.xxx.xxx.xxx Bcast:194.190.163.230 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:52535 errors:0 dropped:413 overruns:0 frame:0
TX packets:47767 errors:0 dropped:0 overruns:0 carrier:0
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
RX packets:70297 errors:0 dropped:0 overruns:0 frame:0
TX packets:47770 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6756101 (6.7 MB) TX bytes:65131309 (65.1 MB)
Смущает заметно меньший RX на бридже, чем на физическом устройстве, при том что TX одинаков
Разве пакет попавший физически на eth0 не должен считаться попавшим и в бридж? И количество дропов разное при том что имеется только один физический интерфейс.
br0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
inet addr: xxx.xxx.xxx.xxx Bcast:194.190.163.230 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:52535 errors:0 dropped:413 overruns:0 frame:0
TX packets:47767 errors:0 dropped:0 overruns:0 carrier:0
eth0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx
RX packets:70297 errors:0 dropped:0 overruns:0 frame:0
TX packets:47770 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:6756101 (6.7 MB) TX bytes:65131309 (65.1 MB)
Смущает заметно меньший RX на бридже, чем на физическом устройстве, при том что TX одинаков
Разве пакет попавший физически на eth0 не должен считаться попавшим и в бридж? И количество дропов разное при том что имеется только один физический интерфейс.
Оставить комментарий
Bird_V
Есть хост - Ubuntu 11.04 (GNU/Linux 2.6.38-13-server x86_64 KVM (1:84+dfsg-0ubuntu16+0.14.0+noroms+0ubuntu4.5 iptables v1.4.10В нём крутится гость - Ubuntu Lucid (внутренний IP 192.168.122.209). В силу непреодолимых обстоятельств (жадности и бюрократичности местных админов) внешний IP имеется только один - у хоста. Задача: пробросить часть портов (22, 80, 143) с хоста на гостя.
Делаю всё по инструкции, но наблюдаю полный облом - connection timed out. Вот какие правила прописаны на хосте:
Выдача ifconfig на хосте:
Зайти с хоста на гостя я могу:
Вопрос: что я ещё забыл сделать?