The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы  помощь  поиск  регистрация  майллист  ВХОД  слежка  RSS
"Сайт во внутренней сети должен быть виден в Инете"
Вариант для распечатки Архивированная нить - только для чтения! 
Пред. тема | След. тема 
Форумы Настройка Squid и других прокси серверов (Public)
Изначальное сообщение [Проследить за развитием треда]

"Сайт во внутренней сети должен быть виден в Инете"
Сообщение от Kouzma Искать по авторуВ закладки(ok) on 01-Ноя-04, 14:39  (MSK)
Имеется внутренняя сеть, в ней есть машина (к сожалению, доступа к этой машине непосредственно не имею, за него отвечают другие люди, которым мне нужно дать решение проблемы) под FreeBSD, на которой есть веб-сайт на порту 80 (к примеру www.site.org), прокси (squid) и выход в инет (назовем ее для определенности gate). На другой машине (пусть будет internal) внутри сети есть другой сайт (допустим, internal.site.org). Необходимо сделать так, чтобы этот внутренний сайт был виден из инета по своему имени ( http://internal.site.org/ )
Насколько я понял, нужно на DNS указать что internal.site.org находится на машине с IP-адресом внешнего интерфейса той шлюзовой машины (gate), а на самой gate перенаправлять запросы (и ответы на них) идущие к ней на имя internal.site.org с внешнего интерфейса во внутреннюю, на машину internal.
Спрашивал у знакомых, говорят, что все это реально, но как - никто точно не знает. :-(
Кое-кто говорил, что для этого необходимо внутренней машине internal присвоить уникальный IP-адрес интернета. (Я склонен интуитивно не поверить).

Видел совет в одной из нетей форума на этом сайте:
(http://www.opennet.me/openforum/vsluhforumID12/2593.html)

> как я понимаю нужно пробросить порт с внеш ip на локальный по нужным портам?
> сквид тебе тут не помощник, в айпитаблесе  это примерно так:
> Обозначения
> $EXT_R_IP - внешний IP роутера
> $LOCAL_IP - внутренний "фэйковый" адрес машины, которую надо "выкидывать" наружу
> $PORT1 - Порт, на который будут заходить извне и попадать на локальную машину
> $PORT2 - Порт, который "выбрасывается" наружу(например, 80 - http, либо 21 - ftp)
> На роутере говорим следующие команды(от рута)
> iptables -t nat -A PREROUTING -p tcp -d $EXT_R_IP --dport $PORT1 -j DNAT --to-destination $LOCAL_IP:$PORT2
> iptables -A FORWARD -i eth0 -d $LOCAL_IP -p tcp --dport $PORT2 -j ACCEPT

Есть возможность это проверить внутри локалки.
То есть рядом с internal есть еще пара машин:
linux (Linux XP Pro - Fedora Core 1), с ней я могу делать что угодно, доступ полный;
wintest (Windows 2000) - изображать на ней клиента, к этой машине тоже полный доступ.

На linux запустил команды:

(здесь и далее: 192.168.3.82 = linux;
192.168.3.94 = internal)

/sbin/iptables -t nat -A PREROUTING -p tcp -d 192.168.3.82 --dport 8080 -j DNAT --to-destination 192.168.3.94:80
/sbin/iptables -A FORWARD -i eth0 -d 192.168.3.94 -p tcp --dport 80 -j ACCEPT

Пытаюсь открыть на linux и на test в браузерах http://192.168.3.82:8080/ , а оно мне: Could not connect to remote server 192.168.3.82 Хотя и инет работает и местный тестовый сайтик на 192.168.3.82:80.

Запустил nmap -p 8080 -v 192.168.3.82
Ответ:
Host linux (192.168.3.82) appears to be up ... good.
Initiating SYN Stealth Scan against linux (192.168.3.82) at 13:20
The SYN Stealth Scan took 0 seconds to scan 1 ports.
Interesting ports on linux (192.168.3.82):
PORT     STATE  SERVICE
8080/tcp closed http-proxy

Nmap run completed -- 1 IP address (1 host up) scanned in 0.320 seconds

Запустил /etc/init.d/iptables status
Ответ:
Table: nat
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
DNAT       tcp  --  anywhere             linux  tcp dpt:webcache to:192.168.3.94:80

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Table: filter
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination
RH-Firewall-1-INPUT  all  --  anywhere             anywhere
ACCEPT     tcp  --  anywhere             internal tcp dpt:http

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain RH-Firewall-1-INPUT (2 references)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
ACCEPT     icmp --  anywhere             anywhere           icmp any
ACCEPT     ipv6-crypt--  anywhere             anywhere
ACCEPT     ipv6-auth--  anywhere             anywhere
ACCEPT     all  --  anywhere             anywhere           state RELATED,ESTABLISHED
ACCEPT     tcp  --  anywhere             anywhere           state NEW tcp dpt:http
REJECT     all  --  anywhere             anywhere           reject-with icmp-host-prohibited

Я так понял, машина linux почему-то не принимает ничего на порт 8080, потому что он закрыт, как утверждает nmap.

Запустил /usr/sbin/tcpdump host 192.168.3.82 and port 8080
На машине wintest в браузере запросил http://192.168.3.82:8080/

Ответ tcpdump:
tcpdump: listening on eth0
12:06:14.138611 wintest.2454 > linux.webcache: S 3467574079:3467574079(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
12:06:17.131253 wintest.2454 > linux.webcache: S 3467574079:3467574079(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)
12:06:23.166777 wintest.2454 > linux.webcache: S 3467574079:3467574079(0) win 65535 <mss 1460,nop,nop,sackOK> (DF)

3 packets received by filter
0 packets dropped by kernel

А так выходит, что порт 8080 (webcache) открыт, хотя в браузерепоявляется через несколько секунд: Could not connect to remote server 192.168.3.82.
Если в браузере на машине linux обращаюсь к http://192.168.3.82:8080/
ответ тот же, но приходит мгновенно, а tcpdump молчит как рыба.

Если что не так - извините, ведь я изначально - программист, опыта администрирования нет, сисадмином только неделю как устроился на новую работу.

Интересно, дочитал ли хоть кто-нибудь до этой строчки?

P.S. Очень прошу помочь!

  Рекомендовать в FAQ | Cообщить модератору | Наверх

 Оглавление

Индекс форумов | Темы | Пред. тема | След. тема
Сообщения по теме

1. "Сайт во внутренней сети должен быть виден в Инете"
Сообщение от Андрей Слободяник emailИскать по авторуВ закладки on 01-Ноя-04, 18:27  (MSK)
>Кое-кто говорил, что для этого необходимо внутренней машине internal присвоить уникальный IP-адрес
>интернета. (Я склонен интуитивно не поверить).
Так можно, если есть лишний ip-адрес. И на главном gate настроить маршрутизацию для этого адреса. Но, если всё на одном ip...

>/sbin/iptables -t nat -A PREROUTING -p tcp -d 192.168.3.82 --dport 8080 -j
>DNAT --to-destination 192.168.3.94:80
>/sbin/iptables -A FORWARD -i eth0 -d 192.168.3.94 -p tcp --dport 80 -j
>ACCEPT

Совет выше был правильный. А у тебя не работает, потому что:
1) 192.168.3.82 и 192.168.3.94 скорее всего в одной сети, общаются напрямую, без всякого gate.
2) в прероутинге нужно переправлять пакеты с _внешнего (реального)_ ip-адреса.

Если хочешь, что всё работало одинаково и снаружи, и внутри локалки, почитай iptables-tutorial в переводе Киселёва, там разобран этот пример; руководство можно найти здесь, на опеннете.

  Рекомендовать в FAQ | Cообщить модератору | Наверх

2. "Сайт во внутренней сети должен быть виден в Инете"
Сообщение от blackpepper Искать по авторуВ закладки on 03-Ноя-04, 11:57  (MSK)
>Имеется внутренняя сеть, в ней есть машина (к сожалению, доступа к этой
>машине непосредственно не имею, за него отвечают другие люди, которым мне
>нужно дать решение проблемы) под FreeBSD, на которой есть веб-сайт на
>порту 80 (к примеру www.site.org), прокси (squid) и выход в инет
>(назовем ее для определенности gate). На другой машине (пусть будет internal)
>внутри сети есть другой сайт (допустим, internal.site.org). Необходимо сделать так, чтобы
>этот внутренний сайт был виден из инета по своему имени (
>http://internal.site.org/ )
>Насколько я понял, нужно на DNS указать что internal.site.org находится на машине
>с IP-адресом внешнего интерфейса той шлюзовой машины (gate), а на самой
>gate перенаправлять запросы (и ответы на них) идущие к ней на
>имя internal.site.org с внешнего интерфейса во внутреннюю, на машину internal.
>Спрашивал у знакомых, говорят, что все это реально, но как - никто
>точно не знает. :-(
>Кое-кто говорил, что для этого необходимо внутренней машине internal присвоить уникальный IP-адрес
>интернета. (Я склонен интуитивно не поверить).
>

Надо смотреть в сторону перенапраления портов.
Вообще по этой теме есть несколько вариантов
1.найти пакет ipmasqadm и читать-читать,
2.запустить локальный proxy-сервер для служб, доступ к которым ты собираешся обеспечить,
3.если твоя локалка имеет IP-адреса, допустимые для использования в Internet. В этом случае взаимодействие происходит следующим образом. На внешний интерфейс приходит пакет, адресованный одному из компьютеров внутренней сети. Брандмауэр перенаправляет соединение соответствующего типа указанному локальному узлу. Приведенное ниже правило обеспечивает перенаправление соединения Web-серверам, работающим в локальной сети.
ipchains -A forward  -i $SERVER_LAN_INTERFACE -p tcp \ -S $ANYWHERE $UNPRIVPORTS \ -d WEB_SERVER 80 -j ACCEPT
В данном случае внешние узлы могут устанавливать соединение лишь с Web-сервером. Другие типы служб, поддерживаемые на компьютерах локальной сети, остаются недоступными.
4.организовать DMZ одним из двух способов
а)использование бастиона с тремя интерфейсами (один наружний,второй в локалку,третий в DMZ ,где ставишь веб-сервер),
б)использование бастиона и заглушки,где заглушка выполняет роль шлюза между DMZ и локалкой, где опять же веб-сервер распологаешь в DMZ.
5.Лучше всего расположить веб-сервер у провайдера ,хай они занимаются вопросами защиты,да и каналы потолще.
  

  Рекомендовать в FAQ | Cообщить модератору | Наверх


Удалить

Индекс форумов | Темы | Пред. тема | След. тема
Пожалуйста, прежде чем написать сообщение, ознакомьтесь с данными рекомендациями.




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру