Как адекватно сделать перенаправление https на файлохранилище?
Приветствую всех, обращаюсь с достаточно глупым вопросом, который до сих пор не даёт мне покоя, поэтому заранее извиняюсь.
Ситуация следующая: для офиса необходимо обеспечить доступ к файлохранилищу через Интернет. В качестве пограничного маршрутизатора используется микротик. Идея заключалась в том чтобы сделать проброс трафика, идущего напрямую к внешнему адресу маршрутизатора по порту 80 и 443 на файлохранилище.
Однако системный администратор, работающий в компании, утверждает что при такой настройке из локальной сети офиса не будет доступа к сайтам, потому что весь трафик будет отбрасываться файлохранилищу.
Вопрос: действительно ли при такой конфигурации отвалятся сайты, и если да, то каким обходным путём можно поступить?
UPD: Видимо стоило догадаться что надо было описывать суть вопроса как можно подробнее, но что поделать, первый вопрос в Хабре.
Постараюсь разъяснить что да как.
Компанией был куплен DELLовский сервер, на котором было принято решение сделать облачное хранилище. После того как я собственно устроился в компанию техником, заместитель технического директора дал задачу настроить на этом сервере облако. То бишь выбор облака и варианта настройки пал полностью на мою голову. С NextCloud я был более менее ознакомлен и поэтому договорились что будем использовать его. На сервере сейчас стоит nginx, база данных и сам Nextcloud, конфиг для nginx взят с официального сайта, но скорректирован на 80 порт, ибо даже сертификата на него нет и доменного имени. У регистратора домена соответственно добавлена запись для файлохранилища. Сейчас доступ к нему обеспечивается по порту 8080, но заместитель технического директора говорит что будет неудобно постоянно указывать порт, чтобы работать с облаком. И соответственно на этом моменте и начались вышеупомянутые вопросы
На сервере сейчас стоит nginx, база данных и сам Nextcloud, конфиг для nginx взят с официального сайта, но скорректирован на 80 порт, ибо даже сертификата на него нет и доменного имени.
Можно использовать бесплатный сертификат от LetsEncrypt.
У регистратора домена соответственно добавлена запись для файлохранилища. Сейчас доступ к нему обеспечивается по порту 8080, но заместитель технического директора говорит что будет неудобно постоянно указывать порт, чтобы работать с облаком.
Использовать порт 8080 не камельфо, так же многие браузеры будут ругаться на отсуствие https.
Есть другие ресурсы опубликованные на 80 и 443 порту микротика?
Проблема оказалась достаточно тупой и даже немного стыдно за то, что я поднял этот вопрос.
Дело в том, что на микротике во время теста сисадмин прописал следующее правило:
action=netmap chain=dstnat dst-port=80 to-address=192.168.90.182 to-port=80
dst-address не указывался, из-за чего по понятной причине маршрутизатор хапал весь трафик на файлохранилище, не выпуская в интернет.
Я хочу поблагодарить всех кто откликнулся и приношу извинения за пустую трату времени, надеюсь таких недоразумений больше не будет
Не зарекайтесь, будет ещё кууча недоразумений. Даже у профессионалов глаз замыливается и случаются невероятно идиотские ситуации. Относитесь с долей юмора. ))
Ивор Барханский, постараюсь, как-никак и сам палки себе в колёса ставлю. Просто ситуация уж неловкая вышла, крыша ехала от безумных идей только так (поскольку мы на этой точке застряли на месяц)
Harpin NAT решит проблему, но я рекомендую этот вариант опустить вниз списка возможных решений. Наиболее оптимальным являет использовать DNS.
Например у вас есть домен example.com и шара в этом домене share.example.com. Соответственно на внешних DNS вы прописывает share.example.com на белый IP микротика, а на самом микротике в IP-DNS-server статическую запись share.example.com на внутренний адрес этого сервера. Соответственно все клиенты внутри сети должны использовать в качестве DNS сервера микротик и при попытке обратиться share.example.com микротик вернет им внутренний адрес сервера.
AUser0, Если ты высунешь свой DNS на микротике жопой в мир и клиенты из глобальной сети начнут его использовать (по какой-то неведомой причине) - то да, вернет, но в здравом уме так никто не делает.
Речь идет о внутренних клиентах. DNS запросы из локальной сети проходят через микротик и в этот момент микротик может возвращать внутренний адрес сервера. Клиенты из глобальной сети пользуют публичные DNS и соответственно подключаются через белый IP микротика на котором настроен проброс на внутренний сервер.
из локальной сети офиса не будет доступа к сайтам, потому что весь трафик будет отбрасываться файлохранилищу.
Согласен информация в задаче не полная. Так же не указано какие сайты будут не доступны. Из чего я делаю вывод, что админ уже протестировал эту схему, при настройке он сделал слишком простое правило для Harpin NAT и начал перехватывать все запросы на 443 и 80 порты без указания назначения, что соответственно перенаправило все запросы в мир на эти порты на внутреннюю шару.
1. Уволить сисадмина вашего. Он не компетентен
2. Пробрасывайте, всё будет работать. Единственно для доступа из локалки по доменому имени понадобится еще настроить Harpin NAT
Благодарю за ответ, будем тестировать. Могу ли поинтересоваться что из себя представляет Harpin NAT? Сисадмин может и не компетентен, но я и сам пока только студент, уж чувствую что мне что-то серьёзное поручать пока рановато.
NetworkAlex, открытие ВХОДЯЩИХ портов на ваш внешний IP не может влиять на доступ на ИСХОДЯЩИЕ порты 80\443 до сайтов)) это же азы сетевого взаимодействия и работы NAT... такое впечатление что у него даже базы нет в голове (
Drno, прежде чем отправлять сисадмина пенсию, хорошо бы отпределиться в понятием файлохранилище. Что же это такое, HTTP, FTP, SMB, или вообще ленточный накопитель с зелёным терминалом? Может сисадмин не так уж и не прав?
NetworkAlex, если этот Nextcloud использает HTTPS - то просто ставите на ваш web-сервер реверсивный прокси (nginx удобнее всего) и настраиваете proxy_pass на адрес своего файлохранилища. Ну и отдельный домен конечно - реверсивный прокси различает HTTP трафик по доменному имени.
А кто автор вопроса в компании - генеральный директор или стажёр который зачем-то хочет доступ из вне к ресурсам компании ?
Может сисадмин знает что-то чего не знает студент, и целенаправленно не даёт доступа.
Что там за информация, что будет когда каждый сможет заходить на этот ресурс, насколько увеличится проблема несанкционированного доступа левыми людьми. И много иных вопросов которые студенты не в состоянии понять.
Но вместо прямого посыла на три буквы, мягко говорит нет оправдываясь техническими отмазками.
AUser0, в вопросе есть ответы на твои вопросы...
насчет обратного прокси - если бы у них был веб сервер доступный снаружи, это по идее должно быть указано в вопросе. в противном случае я считаю что "облако" это единственный веб сервер
aleks-th, ответ бы только в контексте вопроса и полученных данных. догадываться что там да как мне лениво
и не на пенсию - а заниматься самообразованием)
NetworkAlex, можно сделать немного иначе: пользователь вводит доменное имя файлохранилища (с 80-м и 443-м портами по умолчанию), а web-сервер, на который приходит этот запрос, просто перенаправлят запрос на доменное_имя:8080. Соответственно запрос попадает уже на файлохранилище, все довольны. Кроме зам. тех. директора, потому что в адресе светится :8080.
Ну или второй вариант, настраивайте на основном web-сервере проброс файлодомена через proxy_pass, и всё будет работать на 80/443 порту.
AUser0, в принципе звучит как неплохое решение и практика с работой прокси, но ситуация такая что запрос приходит на маршрутизатор, внешнего веб-сервера нет (либо я не так понял суть решения), сейчас маршрутизатор принимает запросы с порта 8080 и пересылает их на 80 порт
NetworkAlex, внешнего web-сервра у вас нет? То есть из Интернета ни кто на web-сервер не заходит? И что значит "принимает запросы _С_ порта 8080"? И почему пересылает запросы на 80-ый порт, если файловый сервер у вас работает на порту 8080?
После этого комментария вообще ничего непонятно, стало.
AUser0, сколько раз говорил себе что объяснять не мой конёк, но видимо я опять попался на свою же ловушку...
Сервер с файлохранилищем и nginx находится в локальной сети. С внешней сети он получает запросы через маршрутизатор, то бишь на нём стоит Destination NAT, который берёт весь трафик, идущий на его внешний адрес по порту 8080 и пересылает его на файлохранилище, меня destination port с 8080 на 80
maxsmeller, в том-то и дело что нет. Как я и описал, идея была в том чтобы на микротик накинуть правило, которое весь трафик с внешнего адреса с портом назначения 80 собственно перебрасывал на файлохранилище с портом 80, но сисадмин компании говорит что если так сделать, то с локальной сети всё сайты, которые работают по http (и https т.к. нужно и 443 порт пробросить) не смогут отправлять ответ клиентам, потому что они будут идти файлохранилищу
NetworkAlex, я правильно понял, что он про то, что сторонние сайты не смогут вернуть ответ пользователям, не ваши внутренние, а любые снаружи? Твой системный администратор - идиот, проброс портов не так работает.
У меня сейчас дома keenetic -> mini-pc, порты 80 и 443 проброшены на mini-pc, на нем nginx сидит в качестве веб сервера. При этом интернет дома работает отлично. Потому что я не идиот в отличии от твоего сисадмина?
maxsmeller, да, так и ответили. Увы я сам повёлся на его слова и решил что "он говорит что-то дельное", потому что мол он старше меня и я только два месяца назад закончил колледж, но будто нутром чувствовал что что-то не так
NetworkAlex, сайты твоим ПК, которые за натом сидят, будут отвечать не на 80 и 443 порт, это твои машинки к сайтам по этим портам будут обращаться. А ответ будет возвращаться на тот порт, с которого запрос улетит, а там НАТ и все дела. Это в первом приближении.
maxsmeller, в одном из комментариев здесь ответили, что скорее всего сисадмин неверно настроил правило NAT, из-за чего тупо весь трафик 80 и 443 сбрасывался на файлохранилище. К счастью дадут возможность посмотреть что там натворили
NetworkAlex, да пусть сбрасывается... это же ВХОДЯЩИЙ трафик... исходящий же по принципу работает.
если конечно он не сделал правило перенаправить и исходящие тоже...
Drno, это и имелось в виду. Мне уже реально интересно посмотреть что там сделано с NAT, спасибо что помогли прояснить ситуацию, завтра напишу результаты
