Статья Делаем локальный сайт (на localhost) доступным для других компьютеров
Эта статья для тех, у кого есть сайт на локальном сервере и кто хочет сделать его доступным с других компьютеров. Кстати, если у вас ещё нет локального сервера, то вы с лёгкостью его поставите по этой инструкции. Подразумевается, что ваш сервер установлен по указанной инструкции, если это не так, то файлы могут находится в других директориях.
- внутри квартиры (всегда);
- внутри локальной домашней сети (почти всегда);
- для всех пользователей Интернета (не всегда).
Разница в вероятностях (всегда-иногда) заключается в вашем IP. Если он статический, то всё делается довольно легко. Как делать локальный сервер при динамическом IP в этой статье не описывается.
Внутри своей квартиры вы сами задаёте политику присвоения адресов — например, Wi-Fi роутер может раздавать устройствам произвольные, динамические IP адреса; и можно настроить роутер и устройства так, что всем им будут присвоены определённые статические адреса.
Домашние локальные сети, как правило, организовываются региональными провайдерами. Внутри этих сетей все пользователи, обычно, имеют два IP: один — локальный (статический, который пользователь вписывает при настройки комьпютера или сетевого оборудования) второй — динамический который присваивается при доступе в Интернет.
Локальные адреса, в основном, имеют такой вид (вместо нулей должны быть другие цифры):
Открываем файл C:ServerbinApache24confhttpd.conf и ищем там строчку
Сохраняем файл и перезапускаем сервер. На самом деле — всё!
Пробуем доступ к серверу набрав в строке браузера свой IP (я набираю http://192.168.43.90/ ), как и следовало ожидать — доступа нет, но причина очевидна: файервол. Его нужно настроить должным образом, но для нашего тестирования я его просто отключаю.
Теперь всё впорядке и ваш сайт доступен по адресу http://192.168.43.90/ с любого устройства, находящегося в вашей домашней или городской сети. На следующем скриншоте, я зашёл на локальный сервер с телефона:
24 часа в сутки
Если у вас статичный IP для интернет соединений (у некоторых Интернет провайдеров можно подключить эту услугу за отдельные деньги), то вы можете сделать из своего компьютера самый настоящий хостинг-сервер! Понятное дело, что компьютер должен быть включен 24 часа в сутки, иначе на ваш сайт невозможно будет попасть.
Внутри локальной (домашней) сети вы можете придумать имя своему сайту и попросить ваших друзей и всех тех, кто будет заходить на него внести изменения в файл
C:WindowsSystem32Driversetchosts
Каждому из них нужно будет добавить туда строчку:
ваш_IP ваш_сайт
например
192.168.43.90 alexblog.local
После этого набирая в адресной строке браузера http://alexblog.local они будут попадать на ваш сайт.
Зачем все эти сложности?
Открытие доступа к локальному серверу может быть полезным по ряду причин, правда, обычно они довольно специфические. Те, кто этим занимаются, знают для чего они это делают. Сейчас, когда не нужно платить за трафик (но нужно платить за электричество), гораздо разумнее разместить свой сайт (доступ к которому вы хотите открыть для всех) на хостинге.
Более того, открывая доступ к своему localhost нужно подумать о безопасности. В данной статье я этот вопрос не затрагиваю, но могу вас заверить, что Apache, запущенный от имени администратора (а именно так он у большинства на локахосте и запущен), через скрипты PHP (или уязвимости в них), может «путешествовать» по каталогам дисков. Т.е., по крайне мере теоретически, злоумышленник через уязвимости в вашем сайте может скачать файлы с вашего компьютера или удалить файлы, например, в директории Windows. Если заботиться о безопасности локального сервера является слишком сложным занятием для вас, то ответ очевиден — хостинг.
How to expose a local development server to the Internet
![]()
Our ambition at Botfuel is to provide the chatbot industry with the best chatbot development tools imaginable. We found no better way to battle-test our products than being our own client by developing chatbots ourselves. As a bot developer, I wanted to share some hard-earned lessons to improve my productivity.
For any developer remotely involved with networking, it is quite common to need to make a local server reachable from the outside. This is particularly the case for chatbot development. If you are developing a chatbot on Facebook Messenger, you probably want to configure the messenger endpoint to point to your local workstation.
Unfortunately, we work most of the time from private IP networks, be that at the workplace, at home or at the coffeeshop. The router(s) that stands between our workstation and the internet makes it harder to expose a local socket to the outside. Most of the time, this is preferable for security. Be sure to understand the risks before allowing anyone to access your local sockets!
Powerful tools exist to expose local services. However it is sometimes hard to find relevant documentation and examples. This article explains what you need to know to cope with most of the situations.
Why isn’t my IP public?
A typical home network is composed of a router and a number of devices connected to the router. The router is assigned a public IP address by the internet provider. Every device in the home network, including the router itself, is assigned a private IP address, usually in the form 192.168.x.x. The router acts as a gateway between the home devices and the internet. This gateway performs network address translation (NAT) between the public and the private networks. While this allows a local device to reach a public IP address, it is usually not possible to initiate a communication from the outside.
For most of the internet users, this is overall a great thing. It mitigates the IPv4 address exhaustion and it provides a way to share an internet connection. Furthermore, it protects the private networks from distant attacks. For example, the Network File System protocol is designed explicitly to be used in private networks and exposing it to the outside would lead to high security risks.
Configure your router
A solution is to change the configuration of the gateway so that it allows communication to be initiated from outside.
For example, consider the case where:
- the gateway is reachable from the internet by the IP address 5.6.7.8,
- from the home network, the gateway uses the IP address 192.168.1.1,
- your laptop is connected to your home network with the IP address 192.168.1.10 and you want to expose a server that listens to port 8889.
For most routers, the socket 192.168.1.1:12345 can be permanently linked to 192.168.1.10:8889. Of course you can replace 12345 with any port number that is not already used by your router.
When a remote client sends a request to 192.168.1.1:12345, the gateway knows that it is legitimate traffic that should be forwarded to 192.168.1.10:8889.
In some cases however, you cannot edit the configuration of the router. This is the case when you use the WiFi at a shared office or at a coffee.
Tunneling services
Some services offer you to set up a tunnel between their servers and your local workstation. These services can be very easy and convenient to use and provide advanced features such as monitoring and statistics, domain name and HTTPS support. However, these services are either charged or subject to limits and you may want to avoid a third-party accessing your data.
ngrok is one of those services, with a freemium model. I tested localtunnel which is free but I didn’t have the chance to see it work.
Self-hosted remote port forwarding
If you do not need advanced monitoring features, setting up a tunnel is straightforward using OpenSSH and a publicly accessible server that you control. In short, a SSH tunnel is initiated by the local workstation and it is kept active between your local workstation and the server. This tunnel is used to forward every incoming connection. The NAT router only sees one long-standing connection and it has no way to tell which party initiated each communication. All the traffic is encrypted using symmetric encryption, meaning that no one between the public server and the local workstation can read your data (though Deep_packet_inspection and timing analysis can reveal some information such as which protocol is used behind SSH).
Make sure that the following options are set in the /etc/ssh/sshd_config of the remote server and reload the SSH server if needed:
Set up remote port forwarding (the tunnel) from the local workstation:
- 1.2.3.4 is the public IP address of the remote server
- 8888 is the port the server is listening to
- 8889 is the port of your workstation that you want to expose
- remoteuser is the name of a user that has the right to connect to the server using ssh
- -n prevents reading from stdin, because you don’t want to use the tunnel from the command line
- -N means that you do not want to execute remote commands, just do port forwarding
- -R (as Reverse or Remote port forwarding) means that the connections are forwarded from the remote server to your local workstation, instead of port forwarding where the end that initiates the tunnel is also the one that initiates the communications across the tunnel.
- optionally, you can use a specific ssh key instead of the default
Test
Listen on the destination port of the workstation :
Send message from anywhere in the world :
You should receive “abc” in your workstation’s terminal.
Troubleshooting
If the message is not properly conveyed, the verbose option of the ssh client (-v) is of great use. You can also verify that everyone is listening as expected using netstat:
Summary
Let’s summarise how the tunnel is setup. On your remote server, the OpenSSH server listens on port 22, awaiting for SSH commands. From your local workstation, the SSH client initiates a longstanding tunnel with the SSH server that can persist for days.
Now this is how the tunnel is used: when a HTTP request comes to the remote server (port 8888), the remote server cannot reach directly the client for the reasons exposed before. However, it can use the longstanding SSH connection to transfer all the information to the OpenSSH client. The OpenSSH client forwards the original HTTP request without any modification to localhost:8889.
For the one who created the HTTP request and for the development server, it’s exactly as if they where talking with each other directly. For the servers isolating your local workstation from the outside, the SSH tunnel is just a TCP connection like any others. Your sysadmin could find strange that you keep hours-long connections between your personal computer and a remote server, though.
HTTPS support
Facebook Messenger requires to use HTTPS. Additionaly, it does not accept self-signed certificates. Then, if you want to expose a bot endpoint to Facebook Messenger, this endpoint should have a domain name with a proper certificate and it should support HTTPS. Anyway, it’s always a good idea to use HTTPS, especially if you deal with personal or sensitive data.
Set up DNS
Usually, the provider of your remote server provides also a domain name service. Use the default domain name of your server or change it to a more human friendly name.
Consequently, the remote server must have a DNS set up. The server provider may provide a default DNS but it may be not very human friendly. You can purchase it for about 10$ a year.
Set up HTTPS certificate
Setting up HTTPS used to be a pain. That time seems long over now that Let’s Encrypt and Certbot exist.
The process listening locally can handle HTTPS messages, provided it is properly configured and it has access to the private part of the server certificate. Here is a sample nodejs server configuration:
Set up reverse HTTPS proxy
Sometimes it is more convenient to support HTTPS upstream, for example when you do not want to complexify your listening process. The task of decrypting HTTPS to HTTP can be done by a web server installed on the remote server. nginx excels at that. Here is a configuration that tells nginx to listen HTTPS on port 8888 and forward everything, unencrypted on HTTP, to the local port 8080:
Как создать свой хостинг (сервер) дома для веб-сайта (чтобы сайт был доступен из локальной сети и Интернет). Простейший пример в Open Server при работе в Windows

Если вы создаете свой сайт и хотите, чтобы он работал только в вашей локальной сети, либо вам нужно сначала его «от и до» протестировать, прежде чем выкладывать в сеть (/либо надумали сэкономить средства на платном хостинге) — можно для этого дела «приспособить» свой домашний ПК/ноутбук (сделать его эдаким сервером). Этим, собственно, мы сегодня и займемся.
Благо, что настраивается это всё достаточно легко (самые большие сложности — обеспечить ему стабильность, ведь далеко не каждый из нас сможет ежедневно/ежечасно контролировать работу компьютера, его подкл. к Интернет, нагрузку ЦП и пр. Но об этом я пару слов скажу в итогах).
Еще пара важных нюансов : способ, изложенный ниже, актуален для ОС Windows 10/11; компьютер должен быть подключен или к локальной сети / или к Интернет (в моем примере ПК подкл. к обычному дом. Wi-Fi роутеру, а он в свою очередь к Интернет).
Итак, теперь к делу.
Пошаговые действия
Установка веб-сервера, размещение файлов сайта
ШАГ 1
В качестве веб-сервера я бы порекомендовал остановиться на 📌Open Server. Он достаточно удобный, надежный, имеет кучу опций (можно выбрать версию PHP, MySQL, настроить авто-выполнение скриптов и пр.). Весь перечень функций приведен на офиц. сайте.
После установки (стандартная, поэтому ее не описываю) и запуска Open Server — у вас в трее должен появиться зеленый флажок (значит веб-сервер работает и с ним все в порядке!). 👇
Кстати, часто Open Server не хочет запускаться из-за отсутствия 📌Microsoft Visual C++ (при установке веб-сервера — не отказывайтесь от загрузки этих пакетов).

Open Server установлен и запущен! Горит зеленый флажок в трее, рядом с часами
ШАГ 2
Далее нужно зайти в папку установки Open Server и открыть каталог «Domains» (в моем случае весь путь такой: C:\openserver5.2\domains ).
В этом каталоге нужно создать папку с именем вашего домена (адреса сайта) , например: testforme.site (можно использовать и testforme.ru , и testforme.com , и даже yandex.ru т.д.*). 👇
📌* Но крайне желательно: выбрать такой домен/адрес сайта, который никем не занят, чтобы в последствии вы могли его зарегистрировать у регистратора, если надумаете открывать сайт для доступа из Интернет. Проверку домена на занятость можно выполнить у Рег.ру.
👉 Примечание : в созданном каталоге с именем домена (в моем случае testforme.site ) нужно разместить файлы сайта: движок, HTML-страницы и т.д. В своем примере я создал в этом каталоге 1 файл index.php и добавил в него короткую строку: «Привет! Этот сайт открылся с дом. хостинга» ). Этого хватит для проверки. Установку движка WordPress рассмотрел в конце статьи, здесь не хочу загромождать.

Папка = имя домена (в ней файл index.php, движок сайта)
Настройка Open Server для доступа к сайту по локальной сети (по IP и по доменному имени)
ШАГ 3
Чтобы открыть настройки у Open Server — сделайте правый клик мышки по его значку в трее, и в появившемся меню выберите соотв. пункт. См. скрин ниже. 👇

Настройки Open Server — клик по значку в трее, в меню выбрать оное
Далее в меню «Модули» укажите необходимую версию PHP, MySQL и пр. для работы вашего сайта. Думаю, что для тестового файла (пока что. ) — можно задать параметры примерно как у меня на скрине ниже. 👇

Можно выбрать версию PHP, MySQL и пр. — модули в Open Server
В меню «Сервер» нужно изменить парочку опций:
- разрешить запуск сервера в агрессивном режиме (чтобы допустить его работу, если возникнут незначительные ошибки);
- установить пункт «Все доступные IP» в пункте «IP-адрес сервера» ;
- затем нужно нажать по меню «Сохранить» .

Все доступные IP, перезагрузка
Далее нам нужно узнать 📌локальный IP адрес компьютера, на котором запущен Open Server (по нему можно будет открывать сайт).
Самый простой способ узнать его — 📌открыть настройки роутера и посмотреть список подключенных устройств (впрочем, есть и др. способы). В моем случае напротив имени ПК «alex-pc» значится адрес 192.168.1.2 (он и нужен!). 👇👇
Примечание : кстати, в настройках роутера неплохо было бы сделать этот IP (192.168.1.2, например) постоянно закрепленным за вашим компьютером. Иначе есть риск, что через неск. дней этот IP роутер даст другому компьютеру в вашей сети.

Настройки роутера — узнаем свой локальный IP
Затем в настройках Open Server в разделе «Алиасы» нужно добавить:
- в строку «Исходный домен» свой локальный IP (192.168.1.2 в моем случае);
- в строку «Конечный домен» адрес/домен своего сайта (testforme.site в моем случае). 👇

Алиасы — привязываем IP к домену
👉 По IP 192.168.1.2 — сайт теперь будет доступен со всех ПК/ноутбуков/телефонов в локальной сети (т.е. тех, которые подключены к Wi-Fi сети вашего роутера, например).
👉👉По доменному имени testforme.site — сайт будет доступен только с того компьютера, на котором запущен Open Server. Чтобы сайт был доступен по доменному имени на другом ПК/ноутбуке в локальной сети — нужно на нем открыть блокнот и изменить 📌системный файл hosts (добавить в него строку вида: 192.168.1.2 testforme.site ).

Пример. Из файла hosts
Как это выглядит на примере приведено ниже 👇 (обратите внимание на адресную строку браузера — т.е. сайт доступен одновременно и по IP, и по домену).

Теперь сайт доступен в локальной сети, достаточно указать его IP в адресной строке браузера
Как открыть доступ к сайту из сети Интернет по IP и по доменному имени
Реализуемость этой «штуки» во многом зависит от вашего Интернет-провайдера. Дело в том, что внешний IP-адрес у вас может быть «белым» и «серым» (со вторым ничего не получится. ) . Чаще всего провайдеры сегодня выделяют динамический белый IP, и в этом случае всё должно работать (до смены этого IP).
В общем, в идеале нужно заказать у провайдера услугу выделения «белого статического IP-адреса» (у некоторых компаний услуга уже включена по умолчанию, и вам не нужно ничего делать; у других — покупается и подкл. отдельно: где-то дешево / где-то дорого. ).
В любом случае — попробовать нижеописанное труда не составит (даже, если вы ничего не поняли из вышесказанного и не знаете какой у вас IP)! 🙂
ШАГ 4
Итак.
Сначала нужно узнать свой 📌внешний IP адрес. Для этого достаточно, как уже говорил выше, открыть 📌настройки роутера и посмотреть вкладку «Состояние / инф. о подключении» (в моем примере внешний IP: 92.252.216.210). Запоминаем его!
Далее нам нужно в настройках роутера пробросить порты 80 и 443 на тот ПК, на котором расположен сайт (эти порты по умолчанию используются для подкл. к сайту по http\https). Более простой вариант — ничего вручную не пробрасывать, а просто включить DMZ-хост для вашего ПК (т.е. DMZ для вашего локального IP). Ссылка ниже в помощь! 👇

Узнаем свой IP-адрес (он должен быть белым!), и пробрасываем порты
Затем в настройках Open Server необходимо открыть вкладку «Алиасы» и связать там свой внешний IP с доменным именем. См. скрин ниже. 👇

Добавляем внешний IP в алиасы — Open Server
Попробуйте после этого набрать свой внешний IP в адресной строке браузера (с любого ПК/телефона/ноутбука, подкл. к Интернет). Должен открыться ваш сайт! 👇
Половина задачи выполнена!?🙂

Сайт открывается по IP
ШАГ 5
Если вы хотите, чтобы сайт был доступен по сети Интернет с любого устройства по доменному имени — понадобиться его зарегистрировать. Сделать это можно у спец. 📌регистраторов, например, 📌Бегет / 📌Рег-ру (и при усл., что ваше желаемое имя никем не занято!).
После регистрации доменного имени (покажу на примере Бегет и Рег-ру) — необходимо открыть управление DNS записями и создать запись вида «A 92.252.216.210» (разумеется, указать нужно свой внешний IP!). Т.е. мы этой операцией «говорим» какой IP открывать при обращении к домену!

Меняем A-запись в настройках DNS (у регистратора доменов или у DNS-хостинга)
Кстати, у Рег-ру нужно выбрать беспл. DNS серверы (их), а затем появится возможность добавить A-запись.

Рег-ру — указываем IP-адрес сервера, по которому будет открываться сайт
Затем останется подождать 15-60 мин. (обычно). Сначала при попытке открыть «наш» сайт по доменному имени будет появл. заглушка регистратора, но когда записи обновятся — предстанет сайт!
Важный момент: сайт перестанет открываться, когда провайдер изменит ваш внешний IP-адрес, либо вы выключите свой компьютер (на котором открыт Open Server).

Через 15 мин. сайт стал открываться по указанному IP — всё работает!
Установка движка (например, WordPress) в Open Server
ШАГ 6
1) Сначала потребуется загрузить движок сайта на ПК (обычно, это архив формата ZIP). Для примера я взял WordPress — офиц. сайт: https://ru.wordpress.org/download/releases/
2) Затем нужно запустить Open Server, нажать ПКМ по значку в трее и открыть PHPMyAdmin. См. пример ниже. 👇
Прим.: логин root, пароль вводить не нужно!

Открываем настройки Open Server — PHPMyAdmin
3) После нужно создать базу данных, я для примера ввел «test1» и нажал кнопку «Создать» . См. ниже. 👇

Создать базу данных (пользователь root, пароля нет)
4) Затем в папке «Domains» (она в каталоге с файлами Open Server) нужно создать папку с доменным именем вашего сайта и извлечь в нее архив с файлами движка WordPress (в моем случае путь получился таким: C:\openserver5.2\domains\testforme.site ).
У WordPress за подключение к БД отвечает файл «wp-config-sample.php» — переименовываем его в «wp-config.php» и открываем для редактирования!

Распаковываем файлы WordPress в папку-домен нашего сайта
5) В строку с «DB_NAME» указываем имя нашей созданной базы (в моем случае test1 ), в «DB_USER» вставляем root , а пароль в строке «DB_PASSWORD» оставляем не заданным. См. пример ниже. 👇

Как выглядит открытый wp-config.php в блокноте — редактируем файл
6) Теперь, если открыть адрес нашего сайта в браузере (если вдруг не откроется — перезапустите Open Server!) , — появится приветственное меню с установкой WordPress. Осталось только дать имя сайту, ввести логин и пароль для доступа к админ-панели, и установить движок.

7) Сайт заработал на WordPress! Панелька появилась сверху — вы можете открыть ее для смены темы, добавления новостей и заметок, и пр.


На телефоне тоже открывается! Кстати, как только выключил ПК (на котором Open Server) — сайт сразу же перестал работать. 🙂
Итоги
ШАГ 7
В общем-то, рассмотренный вариант в заметке позволяет относительно просто и быстро развернуть свой сайт и дать доступ к нему пользователям из лок. сети и Интернет.
Однако, есть свои минусы, которые могут любое удобство и экономию превратить в прямо-противоположное:
- во-первых , нужен статический «белый» IP адрес (как правило, это отдельная услуга у вашего Интернет-провайдера. Иногда цена на него стоит дороже, чем 📌арендовать платный хостинг/сервер);
- во-вторых , ПК с веб-сервером и сайтом должен работать 24 часа в сутки (либо посетители должны знать, когда на него заходить 🙂);
- в-третьих , желательно подкл. 📌к двум Интернет-провайдерам, чтобы обеспечить бесперебойный доступ;
- в-четвертых , сайт желательно разместить на SSD накопителе (так он будет открываться быстрее);
- в-пятых , если у вас будет много посетителей, или сайт будет предлагать какую-то ресурсоемкую услугу — то ваш ЦП может начать «испытывать» высокую нагрузку. За ПК работать может стать не комфортно.
- в-шестых , вам нужно на регулярной основе следить за всем этим «добром»: чтобы Интернет работал, IP не менялись, ПК не перегревался (и работал 24 часа в сутки) и пр.
📌 Взвесив все «За» и «Против» получается, что заниматься этим для экономии средств — практически бессмысленно (по крайней мере, во многих случаях).
Другое дело, если вам требуется сделать небольшой форум в лок. сети для друзей, или вы проводите испытания своего сайта перед «большим заплывом» — то почему нет?! 🙂
Выделенный сервер за 25 руб/месяц. Часть 4. Настройка доступа из Интернет.
Теперь, когда наш сервер содержит всё необходимое для создания сайта, нам нужно реализовать еще одну деталь – открыть ему окно в Интернет. «Воткнуть сетевой кабель и всё» – скажете вы. «Не так просто» – отвечу я. Данная статья рассказывает о том, как из локального сервера сделать настоящий действующий интернет-сервер.
Доступ к серверу извне. Внешний IP-адрес.
Интернет – особая среда. Некоторые вещи работают совершенно не так, как кажется на первый взгляд. Вот, к примеру, если вы выходите в Интернет со своего домашнего компьютера, то происходит это так: вы делаете запрос (например, вводите адрес сайта в браузере). После этого информация из Интернета приходит к вам на компьютер.
Казалось бы: все просто и понятно. Но если вы вдруг заходите совершить обратную операцию: сделать запрос с компьютера на работе на ваш домашний и получить ответ, то далеко не факт, что у вас получится это сделать. Скорее всего не получится. Почему?
Давайте немного усовершенствуем картинку из прошлой статьи:

Сразу говорю для специалистов: эта схема полна условностей, да и вообще все иначе, но для простого обывателя она дает некоторое упрощенное представление.
Интернет-кабель, который выходит из вашего дома, приходит к провайдеру, где вся информация, проходящая по нему, так или иначе, обрабатывается.
Вспомним прошлую статью: как получается, что вы выходите в Интернет через один кабель одновременно с нескольких устройств (компьютер, планшет, телефон, телевизор и т.д.)? Роутер (маршрутизатор), установленный у вас дома, обрабатывает всю поступающую с этих устройств информацию, ставит ее в очередь, отправляет по одному каналу. Ответы, которые ему приходят, он раздает каждому отдельному устройству.
Как роутер узнает, что кому отдать? Когда он отправляет данные в Интернет, он помечает у себя, что куда отправил. То, что возвращается с адреса, на который было отправлено, очевидно, предназначено одному из устройств-отправителей, о которых роутер знает.
А теперь давайте представим, что на роутер приходит какая-то информация, о которой он ничего не знает. Какому устройству он должен ее передать? Скорее всего, какому-то заранее предопределенному.
Очень похожая ситуация происходит и у провайдера. Клиентов у него много. Реальные IP-адреса Интернета, которыми он обладает, явно ограничены, и выделять на каждого клиента отдельный адрес – непозволительная роскошь. Как быть? Провайдер ставит, так называемый NAT-сервер (на самом деле это реализуется более технично, здесь упрощение для понимания), который занимается примерно тем же самым, что и ваш домашний роутер.
Работает это так. Берется реальный IP-адрес Интернета, с которого идут все запросы и на который приходят все ответы. Также берется набор внутренних адресов, о которых известно только внутри сети провайдера, но ничего неизвестно в Интернете. Каждому клиенту провайдер раздает внутренний адрес. Когда на NAT-сервер приходит запрос от клиента, сервер записывает внутренний адрес, с которого пришел запрос, и, в дальнейшем, передаст на него ответ из Интернета. Если из Интернета приходит информация, никак не помеченная (например, запрос на наш Cubieboard), NAT-сервер не будет знать, на какой из внутренних адресов ее необходимо переслать.
Этим проблемы не ограничиваются. Провайдеры также используют свой DHCP-сервер для выдачи внутренних адресов клиентам. Таким образом, при каждом подключении к провайдеру, вы будете получать случайный новый внутренний адрес. Сообщить всем посетителям вашего сайта этот новый адрес явно невозможно. Как же быть? Как обратиться к своему домашнему серверу через Интернет. Есть несколько способов. О них ниже.
1 способ. Бюрократический.
Теоретически, вы можете попросить, или даже потребовать от своего провайдера постоянный внутренний IP-адрес. Смысл в том, что если внутренний адрес постоянен, NAT-серверу провайдера можно указать это. Также это можно указать DNS-серверам провайдера, которые смогут обрабатывать запрос сайта по имени домена и сопоставлять это имя с внутренним IP-адресом. Все это технически реализуемо. Но если вы попросите провайдера о такой услуге, то в 99 случаев из 100 он либо пошлет вас в лес, либо скажет, что это невозможно. Так что в скорее всего такой вариант не пройдет или потребует от вас огромной упорности в своем достижении.
2 способ. Дешевый.
Есть в Интернете сервисы, которые призваны решать заданную проблему. Как? Возьмем выдержку из Википедии:
- DynDNS
- NoIP
Здесь, помимо ограничений, накладываемых собственно сервисами, есть и еще одно – ваш домашний роутер должен поддерживать один из таких сервисов. Посмотреть это можно зайдя в его панель управления.
В любом случае для серьезного сайта такая технология не подходит. Только для обучения или домашнего/тестового сервера, к которому нужно иногда обращаться извне.
3 способ. Удача!
Я думаю, из всех читателей найдутся счастливчики, которым их провайдер предоставляет реальный IP-адрес Интернета бесплатно. Как проверить свою удачу?
- Узнаем IP-адрес своего роутера. Он должен показываться в панели управления роутером.
- Узнаем внешний IP-адрес через который вы выходите в Интернет. Сделать это можно через сайт 2ip.ru.
- Если адреса из пунктов 1 и 2 совпадают, то Бинго! У вас реальный IP-адрес.
- Если адреса не совпадают, звоним в компанию провайдера и спрашиваем о возможности получения реального IP-адреса.
Этот способ ничем не хуже способа 4, но, к сожалению, он доступен далеко не всем.
4 способ. Правильный.
Купить/арендовать реальный IP-адрес у своего провайдера. В большинстве случаев за некоторую дополнительную плату каждый провайдер готов предоставить вам реальный IP-адрес. Некоторые делают это за единоразовую плату на все время использования. Другие, такие как мой, предоставляют в аренду с помесячной оплатой. Да, это дополнительные расходы, но до полноценного внедрения технологии IPv6 в нашем несовершенном мире, придется с этим мириться.
После приобретения реального IP-адреса нужно еще раз проверить его, как описано в способе 3. Если все правильно, значит можно идти дальше.
Доступ к серверу извне. Настройка проброса портов в роутере.
Внешний IP-адрес – это хорошо, но у нас же еще есть домашний роутер, за которым скрывается мини-сервер. Поскольку дома вы сами себе царь, Бог и провайдер, здесь все будет проще. Суть в том, чтобы настроить так называемый «проброс портов» в панели управления роутера. Сложность описания этого действия заключается в том, что видов роутеров много и интерфейс настройки проброса портов может отличаться на устройствах разных производителей. В целом ничего сложного в этом нет, главное уловить суть. А суть я рассказывал в первой части статьи.
Ваша задача найти настройки NAT в интерфейсе роутера и указать ему, что входящие соединения (для которых, как мы ранее выяснили, у роутера нет получателя) нужно перенаправлять на наш мини-сервер. Если самостоятельно с этим разобраться сложно, гуглите по фразе «НАЗВАНИЕ_ВАШЕГО_РОУТЕРА проброс портов». Например, вот настройка роутера Zyxel Keenetic.
По умолчанию, если вы наберете в браузере ваш внешний IP-адрес, например:
то будет открываться форма авторизации в панели управления роутером.
Если же вы правильно настроите проброс портов, то у вас должен отработать уже мини-сервер и вы увидите:

Такая картинка в браузере говорит, что все сделано правильно.
Доступ к серверу извне. Подключение домена.
Теперь, когда наш мини-сервер уже отдает html-страницу при запросе по IP-адресу, а вокруг нас витает волшебство системного администрирования серверов, хорошо бы сделать так, чтобы мини-сервер был доступен не по IP-адресу, а по имени домена. Что для этого необходимо? Ну, во-первых, собственно, домен. Предположим, что у вас уже зарегистрировано доменное имя. Далее мы можем пойти одним из двух путей, но чтобы описывать их, сначала немного нескучной теории.
Для связи доменного имени с IP-адресом сервера, на котором расположен сайт предназначены так называемые DNS-сервера. В упрощенном виде их задача сводится к тому, чтобы при вводе адреса сайта в браузере переслать пользователя на нужный IP-адрес. Сложность в том, что DNS-сервер пользователя, который хочет зайти на ваш сайт, должен знать этот ваш IP-адрес. Как он об этом узнает? Ему скажет ваш DNS-сервер. А как узнает ваш? Ему скажете ВЫ! Есть 2 способа сделать это.
Доступ к серверу извне. Подключение домена. Используем DNS-сервер регистратора домена.
Если вы регистрировали домен не в подвальной конторе соседнего дома, то регистратор должен предложить вам бесплатную услугу использования своего DNS-сервера для вашего домена. Этот способ нравится мне больше, чем создание и настройка собственного DNS-сервера, а потому я так и сделал.
Здесь, опять же, настройка будет немного отличаться в зависимости от регистратора. Дам ссылку на пример такой настройки на reg.ru.
Доступ к серверу извне. Подключение домена. Используем собственный DNS-сервер.
Этот способ рекомендую только тем, кто не намерен отключать мини-сервер на длительное время. Панель управления IPSConfig 3 позволяет вам достаточно легко настроить ваш собственный DNS-сервер и внести на него запись доменного имени. Не буду на этом подробно останавливаться, поскольку выбрал первый способ, но если вам интересно попробовать, то вот видеоурок.
От себя добавлю, что минимум нужно настроить A-записи для домена и домена с www(написать 2 строчки). При настройке вы, естественно, указывайте ваш реальный IP-адрес.
После настройки DNS для вашего домена, нужно подождать около суток. Это связано с особенностями работы DNS-серверов. Если вы все сделали правильно, то уже на следующий день при наборе домена в браузере, вы увидите такую же страницу, как когда вводили IP-адрес. Если это произошло, поздравляю – ваш мини-сервер теперь доступен в сети Интернет. Теперь остается настроить сайт, все сервисы и установить Joomla.