H2o: Запретить доступ без запроса хоста

Я не уверен, что это более чистый способ, но мое решение состояло в том, чтобы поместить фальшивую запись вверху, вдохновленную _Зачем настраивать «пустой сервер SSL по умолчанию»? _ @ https://calomel.org/ nginx.html

listen: &listen80
  port: 80

# fake/invalid cert
listen: &listen443_blank
  port: 443
  ssl:
    <<: !file /etc/h2o/default_ssl.conf
    certificate-file: /etc/ssl/h2o/blank.cert.pem
    key-file: /etc/ssl/h2o/blank.key.pem

hosts:
  "_:80":
    listen: *listen80
    paths: &paths_blank
      "/":
        - mruby.handler: |
            acl {
              deny { ! addr.start_with?("127.0.0.1") && ! addr.start_with?("::1") }
            }
        - file.dir: /var/whatever

  "_:443":
    listen: *listen443_blank
    paths: *paths_blank

# The valid domains start from here

@csmk Я попробовал ваш код и получил сообщение об ошибке «Запрещено» при отображении страницы в Google Chrome.

Показан журнал доступа:

123.123.123.123 - - [27/Apr/2018:12:59:00 +0000] "GET / HTTP/2" 403 9 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36"

@ proyb6 , не могли бы вы вставить фрагменты своей конфигурации?

Что ж, «Запрещено» — это предполагаемая ошибка, если вы не настроили ни одного действительного домена.

Я получил доступ с использованием IP-адреса. Он работал по назначению с использованием доменного имени.

@csmk Спасибо, отлично работает ... Тем не менее: если у кого-то есть более простые решения, например, без mruby, я хотел бы знать об этом.

Если у кого есть более простые решения, например без mruby

Я нашел обходной путь, в моем примере выше, удалите часть mruby и укажите file.dir: на пустой каталог, к которому у пользователя, работающего с H2O, нет доступа. Ответ H2O будет 403.

Я думаю, что простое решение может быть на стороне брандмауэра или iptables?

Еще раз спасибо, @csmk . Это выглядит как разумный подход, чтобы обойтись без mruby.

@ proyb6 Типичный брандмауэр, такой как iptables, просто просматривает пакеты (с какого IP-адреса, на какой IP-адрес, какие порты, какой протокол), но не просматривает содержимое HTTP-трафика. С HTTPS он не мог бы даже вникать в детали, даже если бы захотел. Поэтому это не похоже на работающее решение.