Как получить IP-адрес браузера или имя хоста?

Может быть межсетевой экран, который выполняет своего рода NAT, чтобы позволить внутренним клиентам использовать внешнее DNS-имя для доступа к серверу.

Такой же IP-номер, который вы получаете на сайте клиента, на внешнем IP-адресе клиента-сервера? В этом случае вы можете жестко запрограммировать этот IP-адрес. Все внутренние компьютеры за этим брандмауэром будут иметь одинаковый IP-адрес, и вы можете классифицировать их как «внутренние».

Похоже, вам возвращают общедоступный IP-адрес. Заставьте пользователя перейти на http://www.myipaddress.com. Если это тот же IP-адрес, который возвращается вашему программному обеспечению, то это определенно так.

Единственное решение, которое я вижу, чтобы обойти это, - либо заставить их подключиться к машине, на которой установлено приложение asp.net, через VPN, либо использовать какой-либо другой вид аутентификации. Последний, наверное, лучший вариант.

Попробуйте Request.UserHostAddress, который возвращает IP-адрес клиента. Предполагая, что ваша внутренняя сеть использует IP-адреса, зарезервированные для локальных сетей, относительно просто проверить, является ли IP-адрес внутренним или внешним.

Похоже, что между пользователями и сервером на сайте клиента есть прокси-сервер (его не нужно настраивать в браузере). Это может быть внутренний или внешний прокси в зависимости от конфигурации вашей сети.

Я бы избегал использования UserHostName для того, что является эффективной аутентификацией, поскольку он предоставляется браузером во время запроса и его легко подделать. IP-адрес был бы намного более эффективным, поскольку трудно подменить IP-адрес в TCP / IP-соединении (и поддерживать соединение). Это все еще слабая аутентификация, но в этом случае может быть достаточно.

Даже если вы используете IP-адрес, если между клиентом и сервером есть NAT-прокси, вам, возможно, придется согласиться с тем, что все, что проходит через этот прокси-сервер, является доверенным (я предполагаю, что внешние / ненадежные клиенты не проходят через этот прокси).

Если это неприемлемо, вы вернетесь к другим методам аутентификации. Вместо того, чтобы требовать входа в систему или VPN-соединения, вы можете рассмотреть возможность использования постоянных файлов cookie или клиентских сертификатов и предоставлять их только внутренним клиентам, но вам понадобится какой-то способ доставки их клиенту. Вы, безусловно, можете доставить постоянный файл cookie на основе однократного входа в систему. Файлы cookie могут быть подделаны аналогичным образом в том смысле, что UserHostName может быть, однако у вас есть лучшая возможность создать значение cookie, которое менее предсказуемо, чем имя домена.

Я также рекомендую использовать IP-адреса. Я имею дело с той же ситуацией, настраивая систему аутентификации прямо сейчас, и условия, описанные Epso и Robin M, как раз и происходят. Внешние пользователи, приходящие на сайт, сообщают мне свой фактический IP-адрес, в то время как все внутренние пользователи предоставляют IP-адрес шлюзовой машины (маршрутизатора) в частной подсети, в которой находятся веб-серверы.

Чтобы разобраться с этим, я просто проверяю этот IP-адрес. Если я получаю IP шлюза, я предоставляю внутренний доступ. Если я получу что-нибудь еще, они получат внешний, который в моем случае требует дополнительной аутентификации. В вашем - это просто другой интерфейс.