Показать полную графическую версию : [решено] настройка port mapping в squid
Задача в следующем.
локалка 10.125.0.0
необходимо, чтобы клиенты могли ходить на 92.66.34.56 порт 32633.
Как реализовать?
seman, простите за банальный вопрос. Документацию читали?
man squid ?
Вобще squid - это кеширующий прокси сервер.
port mapping вне зоны ответственности squid. Его задача кешировать(проксировать) трафик.
Мапированием портов а, их перенаправлением, занимаются другие пакеты.
seman, из вашего сообщения никаким образом не становится ясным, как устроена сеть?
10.125.0.0 - замечательно. 10.*.*.* - это диапазон приватных сетей.
92.66.34.56:32633 по все видимости реальный IP адрес.
Пусть клиенты ходят, что им мешает?
lxa85
Документацию читали? »
читал. прекрасно понимаю, что squid - это кеширующий прокси сервер.
поэтому и спрашиваю, так как не знаю какие пакеты за это отвечают.
10.125.0.0 - замечательно. 10.*.*.* - это диапазон приватных сетей. »
спасибо. это мне понятно. все классы приватных сетей мне прекрасно знакомы.
сеть простая.
шлюз 10.125.0.150
прокси кольмар на 10.125.0.100, там же dhcp раздает клиентам в диапазоне 10.125.0.104-10.125.0.150
не знаю, что еще здесь нужно пояснять.
от клиентов пинг на 92.66.34.56 не идет. С кольмара все прекрасно пингуется.
Если я не ошибаюсь все можно решить через конфиг кольмара.
acl password proxy_auth REQUIRED
acl all src 0.0.0.0/0.0.0.0
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl to_localhost dst 127.0.0.0/8
acl SSL_ports port 443 563
acl Safe_ports port 80 # http
acl Safe_ports port 21 # ftp
acl Safe_ports port 443 563 # https, snews
acl Safe_ports port 1025-65535 # unregistered ports
acl CONNECT method CONNECT
acl our_networks src 10.125.0.0/24
http_access allow password
http_access allow manager localhost
http_access deny manager
http_access deny !Safe_ports
http_access deny CONNECT !SSL_ports
http_access allow our_networks
http_access deny all
это текущий конфиг. достаточно ли здесь прописать в access листе данный порт и ip, чтобы клиенты могли видеть данный ip?
шлюз 10.125.0.150, прокси кольмар на 10.125.0.100 »
Вот, уже становится понятнее :)
от клиентов пинг на 92.66.34.56 не идет »
что говорит traceroute ?
Верна ли таблица маршрутизации? Шлюз по умолчанию.
С кольмара все прекрасно пингуется. »
Проверить, сравнить сетевые настройки клиента и кольмара. Также посмотреть разрешения на шлюзе.
Если я не ошибаюсь все можно решить через конфиг кольмара. »
ИМХО проще, правильнее, и удобнее( для администрирования в том числе) предоставить эту операцию обработчикам пакетов, iptables например.
lxa85,
Верна ли таблица маршрутизации? »
разрешения на шлюзе - всем и всё.
сделал route print с клиента
Список интерфейсов
0x1 ........................... MS TCP Loopback interface
0x2 ...00 1a 4d 91 2e c9 ...... Realtek RTL8168/8111 PCI-E Gigabit Ethernet NIC
===========================================================================
===========================================================================
Активные маршруты:
Сетевой адрес Маска сети Адрес шлюза Интерфейс Метрика
0.0.0.0 0.0.0.0 10.125.0.150 10.125.0.107 20
10.125.0.0 255.255.255.0 10.125.0.107 10.125.0.107 20
10.125.0.107 255.255.255.255 127.0.0.1 127.0.0.1 20
10.255.255.255 255.255.255.255 10.125.0.107 10.125.0.107 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
224.0.0.0 240.0.0.0 10.125.0.107 10.125.0.107 20
255.255.255.255 255.255.255.255 10.125.0.107 10.125.0.107 1
Основной шлюз: 10.125.0.150
===========================================================================
Постоянные маршруты:
Отсутствует
10.125.0.107 - это клиент
seman, Проверить, сравнить сетевые настройки клиента и кольмара »
-----
что говорит traceroute ? (tracert?) »
-----
от клиентов пинг на 92.66.34.56 не идет. С кольмара все прекрасно пингуется. »
-----
Как я понимаю, было принято решение, если с кольмара пинг идет, перенаправить коиентов на него, попутно закешировать трафик, и отправить пакеты дальше. Так?
-----
Статьи, что мне попались по реализации "прозрачного" прокси сервера, используют iptables(старое название ipchains) для перенаправления запросов и портов. Этим самым я хочу сказать, что portmaping не задача suid.
Ссылки на материал:
Зона особого внимания: Squid (http://squid.opennet.ru/FAQ/my/FAQrus.html)
Мини-HOWTO: Прозрачный Прокси-сервер при помощи Squid (http://www.linuxcenter.ru/lib/articles/networking/transp_proxy_minihowto.phtml) - Обратите внимание на дату публикации! 2003 год! А сама статья писалась в далеком марте 2000 ного.
Bog BOS: Squid (кеширующий прокси для http): установка, настройка и использование (http://www.bog.pp.ru/work/squid.html)
необходимо, чтобы клиенты могли ходить на 92.66.34.56 порт 32633 »
через что (программа)?
от клиентов пинг на 92.66.34.56 не идет »
пинги идут через основной шлюз а основной шлюз у тебя не в сквиде и делать чтото в сквиде не надо для того чтобы он пошел - это надо на шлюзе делать. Кстати что за шлюз - просто модем или сервер какой?
на 92.66.34.56 порт 32633. »
у меня ни пинга нет на этот адрес и телнет не конектится
Alan85
через что (программа)? »
messenger . название позже посмотрю. я прошу прошения заранее. поскольку меня еще не поставили в известность о месте нахождении
данного сервера (92.66.34.56). Завтра выясню точно. предполагаю находится он в сетке провайдера.
главное что комп со сквидом его видит. то же самое нужно научить клиентов.
раньше когда у провайдера была прописана вся подесть наша, и проксика не было все клиенты свободно могли пинговать данный сервер
Кстати что за шлюз - просто модем или сервер какой? »
linux голый. с 2 интерфейсами, от провайдера и в локалку. никак файрволов нет на нем.
провайдер прописал приватный 10.125.0.100 для выхода в инет. то бишь где сейчас сквид.
у меня ни пинга нет на этот адрес и телнет не конектится »
похоже это говорит о том, что этот сервер внутри локалки
никак файрволов нет на нем. »
есть и имя его iptables и с его помощью squid все видит и знает а клиенты нет так как для них NAT закрыт.
Вопрос как настроен прокси сервер? - прозрачный или на порт 3128?
Пока я вижу два выхода:
1. Дергать провайдера чтобы изменил iptables (или самому) именно для этого адреса и порта (разрешил выход на него) и все это делается на линухе шлюзе.
2. Использовать порт-маппинг у клиента с помощью программ типа httport, freecap .
Alan85,
Дергать провайдера чтобы изменил iptables (или самому) именно для этого адреса и порта (разрешил выход на него) и все это делается на линухе шлюзе. »
к сожалению для нас доступ к шлюзу закрыт. То есть на самом линухе, где стоит сквид ничего сделать нельзя? Я правильно понял?
Вопрос как настроен прокси сервер? - прозрачный или на порт 3128? »
настроен на порт 3128. включена аутентификация. На каждом компе работают много че-к. аутентификация там обязательна.
2. Использовать порт-маппинг у клиента с помощью программ типа httport, freecap . »
попробуй решить проблему этим методом...
Ребята провайдер меня отшил, поскольку сказал, что на шлюзе ничего не надо настраивать на шлюзе.
сказал что надо настроить ip forwarding или нат на самом сквиде. (или в сквиде настройки посмотреть)
Подскажите как это сделать на сусе. Может кто делал.
напомню локалка 10.0.120.х
шлюз 10.0.120.160
днс провайдера 62.148.ххх.хх
нужно получить пинг на 62.148.225.34
свид - 10.120.0.100
со сквида пинг идет на этот сервер нормально, с клиентов - нет.
стоит webmin - там смотрел куча настроек по маршрутизации.
Помогите плиз настроить.
Заранее благодарен.
ip forwarding или нат на самом сквиде »
в сквиде этого нет. ip forwarding или нат настраивается в iptables. При этом клиенты обращаются по шлюзу (у тебя на 10.0.120.160 - т.е. не на там где сквид стоит). Поэтому все же воюй с провом (с подобными задачами обращаются ко мне - делаю не отшиваю) или Использовать порт-маппинг у клиента с помощью программ типа httport, freecap - пинга не добьешься но программы пробросишь.
Есть еще вариант но не знаю прокатит ли у тебя.. - у всех сменить шлюз на 10.0.120.100 и уже настраивать iptables на линухе где сквид.
в сквиде этого нет. ip forwarding или нат настраивается в iptables. При этом клиенты обращаются по шлюзу (у тебя на 10.0.120.160 - т.е. не на там где сквид стоит). Поэтому все же воюй с провом (с подобными задачами обращаются ко мне - делаю не отшиваю) или Использовать порт-маппинг у клиента с помощью программ типа httport, freecap - пинга не добьешься но программы пробросишь.
Есть еще вариант но не знаю прокатит ли у тебя.. - у всех сменить шлюз на 10.0.120.100 и уже настраивать iptables на линухе где сквид. »
воевать с ним бесполезно, так как говорит раз у меня пинг идет со сквида - значит все ок с его стороны, а остальное его не касается. Ладно буду что-нибудь придумывать.
Пинг идет с линуховской машины где сквид стоит, а не со сквида это раз. Пинг означает что машина где сквид имеет разрешение проходить через шлюз (настроено на шлюзе) это два. Чтобы разрешить другим проходить через шлюз надо настраивать шлюз это три.
клиентские машины имеют шлюз 10.0.120.160 а не 10.0.120.100 - почему?
А у прова надо просить чтото вроде: "прошу предоставить мне доступ к ip 62.148.225.34 с машины ip 10.0.120.xxx " можно еще указать по какому протоколу, порту, кто инициатор соединения (программа внутри сети или снаружи). Если будут слать на сквид (на программу сквид а не линукс что там) то можешь объяснить что это HTTP/FTP прокси и ничего более (NAT не в его компетенции). Возможно они имеют ввиду что полный выход дали для одной машины а дальше сами типа крутитесь - тогда шлюз не верно указан выходит.
Если будут слать на сквид (на программу сквид а не линукс что там) то можешь объяснить что это HTTP/FTP прокси и ничего более (NAT не в его компетенции). Возможно они имеют ввиду что полный выход дали для одной машины а дальше сами типа крутитесь - тогда шлюз не верно указан выходит. »
ты говоришь все верно и правильно. я им объяснял, что при мне они прописывали удаленно на шлюзе разрешение выходить в инет через только 1 комп, где щас сквид. по поводу шлюза это моя вина. Хотя не знаю можно ли это назвать винной. Просто когда я в Dhcp прописывал шлюз для клиентов, мне не говорили, что планирует в дальнейшем выходить на разные чаты и др сервера. В принципе не проблема поменять шлюз. меня волнует больше настройка iptables. Никогда раньше не настраивал. посоветуй как настроить грамотно. может знаешь ссылки, где можно почитать о настройке.
http://iptables-tutorial.frozentux.net/
доступ к ip 62.148.225.34 с машины ip 10.0.120.xxx " можно еще указать по какому протоколу, порту, кто инициатор соединения (программа внутри сети или снаружи) »
чтобы помочь еще эту инфу надо
чтобы помочь еще эту инфу надо »
программа установлена внутри сети. inbit messenger порт 10883
как я понял установлен сервер этого мессенгера на 62.148.225.34 (10883)
у клиента устанавливаю Ip и порт. и регистрируюсь на сервере.
мне главное добиться пинга до 62.148.225.34. потом придут админы мессенгера и сами все сделают.
протокол уточну попозже
Попробуй вот эти команды если помогут надо будет сохранить их...
Я не гуру в iptables (хоть и приходится сталкиваться по работе), если чтото не так поправте
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.0.120.0/255.0.0.0 -d 62.148.225.34 -j SNAT --to-source 10.0.120.160
iptables -A INPUT -s 10.0.120.0/255.0.0.0 -j ACCEPT
iptables -A FORWARD -s 10.0.120.0/255.0.0.0 -d 62.148.225.34 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
при этом шлюз должен быть настроен на машину где сквид...
Alan85
что-то не хочет пропускать. вроде после ввода команд не было ошибок.
правда возник один глюк. перестал работать инет напрямую и через сквид.
много раз перезагружал - впустую. Потом просто перезаписал squid.conf - заработал,
но только через сквид. напрямую так и неработает. не понимаю что могло задеть.
с учетом некоторых изменений
шлюз - 10.125.0.150
сквид - 10.125.0.101
у клиентов шлюз - сквида
изменил команды на
echo "1" > /proc/sys/net/ipv4/ip_forward
iptables -t nat -A POSTROUTING -s 10.125.0.0/255.255.255.0 -d 62.148.225.34 -j SNAT --to-source 10.25.0.150
iptables -A INPUT -s 10.125.0.0/255.255.255.0 -j ACCEPT
iptables -A FORWARD -s 10.125.0.0/255.255.255.0 -d 62.148.225.34 -j ACCEPT
iptables -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT
© OSzone.net 2001-2012
vBulletin v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.