There’s nothing special in the cloudflare setup. This is just a property of HTTP.
When a client opens a URL, there are three important steps:
- If required, it makes a DNS (or other resolution method) to turn a hostname into an IP address. If the URL specifies an IP address for the host, use that.
- It makes a connection to that IP address on a well-known port number, normally 80 (unless it’s overridden in the URL)
- It asks the server for the page, including the desired hostname.
A classical example looks like this:
GET /pub/WWW/TheProject.html HTTP/1.1
Host: www.w3.org
Consider a large host with many web sites on it. For simplicity let’s say it has a single IP address. Hundreds of domain names resolve to this address. How does the server decide which pages to deliver? It uses the host detail given by the client in the HTTP request. If you ask for something it doesn’t have or want to give you, it will give you an error response.
In your case, the request contains an IP address for the host specifier.
GET /whatever HTTP/1.1
Host: a.b.c.d
Very many hosts decide not to give out pages when the host is specified by IP address. There’s nothing special about Cloudflare here, nor is it to do with DNS. It’s about how the server responds to requests for the host specified by IP address, and you can see that this error message specifies that A valid Host header must be supplied.
Here’s an answer which describes how to configure a server in this way: https://serverfault.com/a/607222
You can easily verify this kind of behaviour by using telnet to connect to a server and issue the HTTP request manually.
PS. The same general answer applies to an HTTPS request, but using Server Name Indication in the setup. It’s worth noting that Host came in with HTTP 1.1 (1997). Prior to that, the mechanism described here didn’t exist, and a server had no way to reliably tell if the client had asked for a name which legitimately resolved to its IP address, or had asked for the host by IP address directly. As this was an important development for the explosive growth in web sites, many older clients were updated to send Host. [Thanks commenters for picking up on details.]
SSL/TLS encryption mode on Cloudflare side is on «flexible» status (https on)
server side setting on third server is:
upstream backend {
server domain1.com;
server domain2.com;
}
server {
listen 80;
location / {
proxy_pass http://backend;
}
Error message is:
Error 1003
Direct IP access not allowed
Cloudflare explains:
Error 1003 Access Denied: Direct IP Access Not Allowed
Common cause
A client or browser directly accesses a Cloudflare IP address.
Resolution
Browse to the website domain name in your URL instead of the Cloudflare IP address.
asked Jan 28 at 15:50
I resolved this problem with set proxy to the header
proxy_set_header Host www.domain.io;
answered Jan 29 at 23:17
Законодательство и IT-бизнес
Рекомендация: подборка платных и бесплатных курсов Python — https://katalog-kursov.ru/
Не так давно заметил что в Билайне заблокированы часть подсетей предоставляемых CDN-сервисом CloudFlare. Причем блокировка ведется именно по IP, т.е. ни по HTTP, ни по HTTPS часть ресурсов, которые в своей работе используют CloudFlare. Под катом, если кому-то интересно примеры и некоторый анализ ситуации.
Началось все с того что одним прекрасным утром я не смог зайти на форум forum.gsmhosting.com, не то чтобы этот ресурс был особенно полезным для меня, но иногда читаю там какие-то новости и просматриваю девелоперские разделы, поэтому факт того что ресурс не открывается для меня стал небольшим сюрпризом. Возможно временные технические проблемы, подумал я, но проверив доступность ресурса вечером — увидел что ничего не поменялось. Тогда я решил попробовать разобраться в чем же дело. В месте подключения заведено два провайдера Билайн (L2TP) и Ростелеком (PPPoE), все это «сведено» через Mikrotik, т.е. используется балансировка нагрузки, попеременный выбор маршрута и т.п. подобные полезные вещи, однако, HTTP и HTTPS открываются именно через Билайн. Посмотрев nslookup’ом A-записи для forum.gsmhosting.com я получил следующее:
Addresses: 104.27.158.203
104.27.159.203
Как видно оба данных адреса принадлежат CloudFlare, настроив маршрутизацию этих IP через Ростелеком — я обнаружил что ресурс вполне работоспособен. Что же произошло?
На странице http://moskva.beeline.ru/customers/help/safe-beeline/ugrozy-v-internete/zablokirovannye-resursy/ у Билайна можно получить информацию о том что оба этих IP адреса действительно попадают в список заблокированных ресурсов:
При этом попытка найти само постановление ФНС 2-6-27/ 2016-06-29-51-АИ успехом не увенчалась. Также, IP-адрес и доменное имя форума были проверены на предмет присутствия в списке заблокированных ресурсов здесь:
- https://eais.rkn.gov.ru/
- http://blocklist.rkn.gov.ru/
Однако и там и там на момент проверки значилось что данные IP адреса или доменное имя не значатся в реестре.
Следующим шагом было обращение в техподдержку Билайна с подробным описанием ситуации, на что был получен следующий ответ:
Заблокирована подсеть 104.27.159.203/32, которая имела отношение к ресурсу marathonbet.cc, доступ к которому был заблокирован по решению ФНС.
Ip 104.27.159.203 на данный момент за ресурсом forum.gsmhosting.com
Обращений в Федеральный Центр Мониторинга от владельцев ресурса не поступало.
Но факт в том, что у другого провайдера — Ростелеком, который также исполняет требования 149-ФЗ forum.gsmhosting.com открывался, а вот заблокированный marathonbet.cc нет, о чем и было сообщено в ответном письме представителям провайдера:
Данная подсеть относится к пулу адресов https://www.cloudflare.com/, если вы понимаете о чем идет речь. Сайтов использующих CDN от CloudFlare не одна тысяча как вы понимаете, поэтому из-за блокировки marathonbet.cc могут пострадать вполне легитимные ресурсы. Данную ситуацию можно сравнить с недавней блокировкой сервисов Amazon S3. Что же касается обращения от владельцев ресурса forum.gsmhosting.com и других «пострадавших» в Федеральный Центр Мониторинга, то здесь как раз все понятно, подобного обращения и не будет, т.к. в Европе просто не в курсе о существовании подобного центра и блокировках чего-либо в России.
Тем неменее у Ростелекома данная блокировка реализована корректно, при попытке открыть marathonbet.cc пользователь автоматом редиректится на страницу заглушку http://warning.rt.ru/?id=13&st=0&dt=104.27.159.203&rs=marathonbet.cc/ с помощью 302 редиректа. Другие сайты расположенные на этом IP по HTTP открываются вполне корректно.
В Билайне же все «интереснее». При открытии что marathonbet.cc, что forum.gsmhosting.com заглушки http://blackhole.beeline.ru/ не выходит, соединение просто режется на стороне Билайна. Из всех возможных решений по реализации блокировки в данном случае, к сожалению, Билайн выбрал самое некорректное.
Надеюсь мне удалось привлечь внимание к существующей проблеме, хотя бы на уровне «конкуренты исполняют требования 149-ФЗ лучше» и в будущем можно будет надеяться на ее разрешение.
p.s. Решением проблемы может быть блокировка указанных IP по HTTPS, при этом при доступе по HTTP провайдеру ничего не мешает анализировать поле Host в заголовке HTTP протокола. В Ростелекоме именно так и происходит.
Однако в ответ я получил простую отписку:
Блокировка такого рода ресурсов производится именно по всей подсети 104.27.159.203/32.
Владельцам ресурсов, не имеющих отношения к ресурсу marathonbet.cc, необходимо обратиться в ФНС, с просьбой снять блокировку, или же обратится к хостинг провайдеру, который предоставляет им адреса из подсети 104.27.159.203/32, с просьбой выдать корректный адрес.
Комментарии про реализацию аналогичной блокировки у конкурентов, естественно, во внимание не приняли, да и судя по всему отвечал обычный сотрудник ТП первого уровня, у которых на любой типовой запрос есть соответствующие инструкции. Других причин именовать один единственный IP адрес 104.27.159.203/32 целой подсетью по-крайней мере я не вижу 
Что же мы имеем в итоге? Множество ресурсов так или иначе пользуется CDN-сервисом от CloudFlare, реализация блокировок у некоторых провайдеров (тот же Билайн) в этом случае реализована по IP, т.е. любые HTTP и HTTPS обращения к заблокированным IP просто «режутся» firewall’ом на стороне провайдера, без какого-либо дополнительного информирования абонента. С другой стороны, некоторые (Ростелеком) реализуют более правильный подход к реализации подобных блокировок, так, например, у них блокировка IP происходит только при попытке обращения по HTTPS, при использовании HTTP другие ресурсы не страдают, т.к. анализируется поле Host в заголовке запроса.
Последующие проверки на тему «как обстоят дела в Билайне» показали что со стороны провайдера заблокированы и некоторые другие ресурсы, A-записи которых принадлежат пулу Cloudflare, причем полностью по IP.
Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.