IP какого уровня показывает страница проверки?
Открывая страницу Проверка IP-адреса, вы видите исходящий адрес, видимый этому сервису в рамках данного запроса. Если сервис использует доверенный обратный прокси, обычно он также извлекает переадресованный адрес клиента согласно своей конфигурации. Этот адрес не обязательно совпадает с адресом сетевой карты компьютера: в домашней IPv4-сети обычно применяется трансляция сетевых адресов (NAT), а выше может находиться ещё один уровень NAT, прокси или VPN. Следует отдельно записывать «адрес конечного устройства», «WAN-адрес роутера» и «значение, видимое на веб-странице», а не называть их все своим публичным IP.
Изменяют ли прокси и VPN веб-выход, зависит от конкретных маршрутов и правил разделения трафика. Прокси браузера может пересылать только веб-запросы, системный VPN может обслуживать только внутренние сегменты сети предприятия; только конфигурация полного туннеля направляет соответствующий интернет-трафик на VPN-шлюз. Поэтому разные приложения одного устройства, соединения IPv4 и IPv6 могут выходить через разные каналы. По одной веб-проверке нельзя определить, кто выдал адрес, является ли он выделенным или использует ли устройство VPN; необходимо судить на основе фактически действующей сетевой конфигурации в данный момент.
Частные или общие адреса обычно следует искать в состоянии локальной сетевой карты, оптического модема или WAN-статуса роутера. Обычный публичный интернет-запрос не должен принимать адреса RFC 1918 или RFC 6598 в качестве глобально маршрутизируемого клиентского выхода; если страница показывает такие значения, сначала нужно проверить, не является ли это локальной информацией или проблемой конфигурации переадресации. Публичность адреса и репутация — разные вещи: маршрутизируемый адрес может иметь историю злоупотреблений, а частный адрес не может напрямую участвовать в сравнении публичной репутации. Подробнее см. Проверка репутации IP: риски, чёрные списки и прокси.
Устройство, роутер и оператор: четыре уровня адресов
Сначала поймите адреса по четырём позициям. Первый уровень — адрес терминала в локальной сети, например 192.168.50.8; второй уровень — WAN-интерфейс домашнего роутера, который может получить публичный адрес или частный адрес, выданный вышестоящим оптическим модемом; третий уровень — сеть оператора: при развёртывании CGNAT адрес на стороне пользователя транслируется оператором и выходит в интернет через публичный адрес, при этом на стороне пользователя может использоваться диапазон 100.64.0.0/10; четвёртый уровень — источник запроса, наблюдаемый целевым сервисом. Если дополнительно используется прокси, целевой сервис видит выход прокси.
Ниже приведён явно помеченный как иллюстративный пример домашнего двойного NAT. Предположим, у пользователя оптический модем настроен оператором в режиме роутера, LAN-адрес модема — 192.168.1.1, и оператор назначил его WAN-интерфейсу публичный IP 203.0.113.10 (иллюстративный адрес, не реальный пользовательский). Далее пользователь подключил беспроводной роутер, WAN-порт которого получает от модема 192.168.1.100, а LAN-адрес — 192.168.50.1. Телефон пользователя получает адрес 192.168.50.8. Когда телефон обращается к сайту проверки IP, пакет сначала проходит через беспроводной роутер, который меняет исходный адрес на 192.168.1.100, затем модем меняет его на 203.0.113.10, и в итоге сервер видит 203.0.113.10. На телефоне локально виден внутренний IP 192.168.50.8, в панели роутера виден WAN IP 192.168.1.100 — оба не являются публичными адресами, но конечный выход публичный. Этот пример служит только для объяснения порядка трансляции адресов и не представляет какую-либо реальную среду пользователя.
Если WAN роутера — 100.64.0.2, а веб-выход — другой глобально маршрутизируемый IPv4, это согласуется с вышестоящей трансляцией адресов, но всё равно требует подтверждения конкретной архитектуры у оператора. Если WAN — 192.168.1.2, возможно, это режим роутера на оптическом модеме, второй роутер или вышестоящий шлюз предприятия; само значение не говорит, какое устройство выполнило NAT. Запись топологии и ролей интерфейсов полезнее для диагностики, чем снятие одного адреса.
Точное определение частных и общих диапазонов адресов
RFC 1918 определяет три частных диапазона IPv4: 10.0.0.0/8, то есть от 10.0.0.0 до 10.255.255.255; 172.16.0.0/12, то есть от 172.16.0.0 до 172.31.255.255; 192.168.0.0/16, то есть от 192.168.0.0 до 192.168.255.255. Все IPv4, начинающиеся с 10, попадают в первый диапазон, но нельзя считать все адреса, начинающиеся с 172 или 192, частными. Отсутствие в этих трёх диапазонах также автоматически не означает возможность публичного использования; следует проверять и другие диапазоны специального назначения.
RFC 6598 определяет общий диапазон адресов 100.64.0.0/10, от 100.64.0.0 до 100.127.255.255, используемый в определённых сценариях внутри сети провайдера и не являющийся глобально маршрутизируемым. Попадание WAN роутера в этот диапазон — важный признак вышестоящей общей сети, но само по себе не доказывает, что оператор реализовал именно CGNAT. И наоборот, отсутствие этого диапазона не исключает вышестоящий NAT: внутренняя адресная схема оператора может отличаться.
При оценке необходимо сравнивать по полному диапазону, нельзя помечать все адреса, начинающиеся со 100, как CGNAT. Общие адреса обычно находятся на стороне до трансляции, а публичная проверка видит глобально маршрутизируемый выход после трансляции — эти результаты не противоречат друг другу. Дополнительно проверьте, проходит ли запрос через прокси, используется ли один и тот же WAN и семейство адресов. Только зафиксировав эти условия, расхождение адресов станет объяснимым признаком; окончательное наличие прямого публичного IPv4 в тарифе подтверждается оператором и фактической конфигурацией сети.
Как сопоставить WAN-адрес и веб-выход
По возможности записывайте исходящий IPv4-адрес веб-страницы в одно и то же время, с одного и того же терминала и в одной и той же сети, а затем сверяйте его с WAN IPv4-адресом маршрутизатора, фактически обрабатывающего запрос. Повторное подключение, переключение Wi-Fi, использование dual WAN или разделение трафика через прокси повлияют на сравнение. Для IPv6 метод проверки иной: терминал обычно имеет собственный глобальный IPv6-адрес, и нельзя требовать, чтобы он совпадал с WAN IPv6 маршрутизатора. Следует проверить исходный адрес, фактически использованный терминалом в этот раз, делегированный оператором префикс и ожидаемый маршрут; временные IPv6-адреса также могут меняться со временем.
В домашней сети сначала просмотрите страницу состояния и текущую топологию; не нужно сбрасывать устройство к заводским настройкам только ради просмотра адресов. Пользователи корпоративных или кампусных сетей могут передать результаты проверки терминала сетевому администратору, который сверит исходящий адрес и вышестоящее преобразование. Если устройство имеет несколько интерфейсов, укажите названия и назначение интерфейсов, различая адрес управления оптического модема, LAN-адрес маршрутизатора, WAN-адрес и адрес виртуального интерфейса VPN, иначе даже несколько правильных значений вместе могут привести к ошибочному выводу.
При одном и том же IPv4-запросе, без прокси и при правильно выбранном WAN, адрес WAN совпадает с исходящим адресом веб-страницы; обычно не поддерживается предположение, что «этот путь дополнительно проходит через CGNAT, изменяющий исходный IPv4». Однако совпадение адресов не гарантирует статического выделения, эксклюзивности или разрешения входящих соединений; политики оператора и брандмауэры хоста и маршрутизатора по-прежнему могут ограничивать доступ. Возможность входящих подключений следует проверять из независимой внешней сети, тестируя собственный управляемый сервис, и отдельно фиксировать протокол, порт и этап, на котором происходит сбой.
WAN-адрес отличается от исходящего — какие еще причины?
Если WAN-адрес отличается от исходящего адреса веб-страницы, в первую очередь рассмотрите фактическую топологию. Когда оптический модем работает в режиме маршрутизатора, нижестоящий маршрутизатор может получать от него частный адрес, образуя двойной NAT; системный VPN также может направлять веб-трафик в интернет через удаленный шлюз. Сначала подтвердите режим работы оптического модема, разделение трафика VPN и интерфейс, фактически обрабатывающий запрос, а затем определите, на каком уровне возникает расхождение. Изменения мостового режима, набора номера или туннельных настроек должны подтверждаться оператором или администратором в соответствии с сетевыми требованиями; нельзя менять способ подключения только ради того, чтобы два числа совпали.
Прокси браузера также изменяет исходящий адрес веб-страницы, тогда как другие приложения на том же устройстве могут подключаться напрямую. Окно инкогнито обычно не обходит системный прокси и не гарантирует отключения всех расширений; конфигурация браузера, используемая для сравнения, должна подтверждать состояние прокси и расширений. Корпоративные безопасные шлюзы, службы удаленного просмотра и многоисходящая маршрутизация также могут вызывать расхождения. Для управляемых устройств обычно эффективнее попросить администратора проверить политики, чем самостоятельно отключать корпоративный туннель.
Исключение по уровням следует выполнять последовательно. Сначала убедитесь, что на устройстве не включены VPN или прокси, затем проверьте, находится ли WAN-адрес маршрутизатора в диапазоне RFC 1918 или RFC 6598. Если WAN-адрес частный, оптический модем, возможно, все еще в режиме маршрутизатора; если WAN-адрес — 100.64.x.x, оператор, возможно, использует CGNAT; если WAN-адрес публичный, но исходящий адрес веб-страницы отличается, вероятно, есть прокси или корпоративный шлюз. Не делайте выводов на основании одного скриншота, поскольку адреса могут динамически меняться, а прокси-программы могут запускаться вместе с системой. Ведите записи наблюдений в несколько моментов времени и сопоставляйте их с изменениями топологии сети, чтобы повысить точность оценки.
IPv4 и IPv6 нужно проверять отдельно
IPv4 и IPv6 обычно развёртываются параллельно, но имеют собственное распределение адресов, маршрутизацию и политики брандмауэра. Терминал может использовать IPv4 через NAT и одновременно напрямую получать глобальный IPv6-адрес. Успешный доступ по IPv6 означает лишь, что в этот раз данный IPv6-путь и сервис доступны; сбой доступа по IPv4 может быть связан с DNS, маршрутизацией, прокси или прослушиванием на стороне сервера. CGNAT особенно важен для входящих IPv4-соединений, для которых не установлено сопоставление; его нельзя использовать для объяснения всех сбоев исходящих IPv4-подключений.
Проверка среды браузера может помочь наблюдать исходящий адрес запроса и сетевое поведение браузера, но на ее основании нельзя доказать, что внешний хост может активно подключаться к вашему сервису по IPv6. Для проверки входящих подключений необходим реально прослушивающий сервис, соответствующие правила брандмауэра и тестирование из независимой внешней сети. Правила разрешения для двух протоколов могут различаться, поэтому «веб-страница может подключиться» и «другие могут входить» следует принимать отдельно; нельзя утверждать, что входящие открыты, лишь потому что страница показывает глобальный IPv6-адрес.
При диагностике отдельно фиксируйте цель, исходный адрес и этап сбоя для IPv4 и IPv6. Если подозреваете, что путь не соответствует ожиданиям от прокси или VPN, ознакомьтесь с Проверка утечек WebRTC, DNS и IPv6: как читать результаты. Кандидаты WebRTC отражают интерфейсы или признаки исходящего адреса, которые браузер может собрать; DNS-тест обычно наблюдает источник рекурсивного резолвера, когда тестовый запрос достигает авторитетного сервера, а не считает целевой IP, полученный при разрешении домена, вашим исходящим адресом. Отключение IPv6 может маскировать проблему; сначала чётко определите, какой именно путь не соответствует ожиданиям.
Как анализировать сбой проброса портов
При сбое проброса портов сначала убедитесь, что локальный сервис запущен и прослушивает ожидаемый интерфейс и порт. Если сервис привязан только к 127.0.0.1 или ::1, внешние устройства не смогут подключиться напрямую; можно привязать сервис к определенному внутреннему интерфейсу в соответствии с потребностями и ограничить доступ с помощью брандмауэра хоста. Перевод сервиса на прослушивание всех интерфейсов не является единственным решением и может расширить поверхность атаки. Сначала проверьте ответ приложения с другого устройства в локальной сети, затем последовательно исследуйте маршрутизатор и вышестоящую сеть.
Если локальное прослушивание и брандмауэр хоста в порядке, следующим шагом проверьте правила переадресации портов на маршрутизаторе. Распространенные ошибки включают: переадресацию на неправильный внутренний IP, несоответствие внешнего и внутреннего портов или выбор протокола TCP, тогда как сервис фактически использует UDP. Некоторые маршрутизаторы также требуют отдельно разрешить этот порт в брандмауэре и перезагрузиться для применения правил. В этом случае можно протестировать доступность сервиса с другой машины во внутренней сети, чтобы изолировать проблему конфигурации маршрутизатора.
Если конфигурация маршрутизатора верна, но входящие подключения по-прежнему не работают, сравните WAN IPv4 с исходящим адресом веб-страницы и проверьте вышестоящий NAT и политики оператора. Проверка TCP-соединения может предоставить внешнее наблюдение в пределах разрешенных инструментом публичных целей и диапазона портов; если ввод отклонен политикой инструмента, это не является доказательством сбоя подключения к цели. TCP-тест также не заменяет проверку UDP-сервисов. При сбое внешнего теста сохраняйте исходную причину, а не списывайте все на CGNAT.
Если внешний тест показывает, что порт недоступен, также рассмотрите, не блокирует ли оператор часто используемые входящие порты, такие как 80, 25, 445 и др. Некоторые операторы по умолчанию блокируют все входящие подключения, пока пользователь не запросит публичный IP или разрешение конкретных портов. В этом случае свяжитесь с оператором для уточнения политики, а не многократно меняйте локальную конфигурацию. Порядок диагностики можно свести к следующему: локальное прослушивание, брандмауэр хоста, переадресация на маршрутизаторе, вышестоящий NAT, ограничения оператора; на каждом шаге меняйте только одну переменную, чтобы точно определить источник проблемы.
Как общий исходящий адрес влияет на капчу и репутацию IP
При использовании общего выходного IP-адреса действия других пользователей могут повлиять на репутацию этого адреса, что приведёт к появлению дополнительных капч или ограничений доступа. Необходимо различать наблюдения на уровне адреса и конкретного пользователя. Наблюдения на уровне адреса лишь показывают, что с данного IP когда-то исходили автоматические запросы или аномальный трафик, но не позволяют определить, кто их отправлял, и не доказывают злонамеренность текущего пользователя. При использовании CGNAT один IPv4-адрес могут совместно использовать сотни и более пользователей, и аномалия любого из них может быть записана сайтом на этот адрес.
В справке Google по аномальному трафику указано, что автоматические запросы других пользователей в общей сети или VPN могут вызывать предупреждение об аномальном трафике. Это возможная причина, но на основе предупреждения нельзя определить, какой пользователь или программа отправила запрос, и нельзя утверждать, что данный выходной узел попал в какой-либо публичный чёрный список. Следует сохранить конкретную ошибку и время возникновения и проверить сеть, браузер и правила целевого сайта отдельно согласно IP в чёрном списке и постоянная CAPTCHA: что делать.
Общий IP-адрес сам по себе не означает небезопасность и не свидетельствует о злонамеренности пользователя. Многие организации используют CGNAT для экономии IPv4-адресов, что является нормальной практикой сетевой инженерии. Оценка безопасности должна основываться на конкретном трафике и сессиях, а не на общем адресе. Если при проблемах с капчей вы обращаетесь к сайту или оператору, можно указать, что вы находитесь в среде с общим выходом, и предоставить наблюдаемые данные о времени доступа и поведении, а не требовать отбеливания всего IP, поскольку отбеливание может скрыть реальные аномалии.
Для владельцев сайтов полагаться на репутацию одного IP-адреса при принятии решений легко приводит к ложным срабатываниям. Более разумно сочетать несколько сигналов, таких как user-agent, TLS-отпечаток, поведенческие модели, и предоставлять пользователям с общим выходом дополнительные способы проверки, например, коды по электронной почте или SMS. Обычные пользователи при учащении капч могут попробовать сменить сетевое окружение или сообщить сайту диапазон выходных IP и время доступа, но не должны использовать инструменты обхода для преодоления контроля доступа.
Что писать в заявке оператору
При подаче заявки оператору чем полнее информация, тем быстрее обработка. Нужно указать точный часовой пояс и время, например конкретную дату и временной интервал в UTC+8, чтобы оператор мог сопоставить логи. Также приложите IP-адрес, отображаемый на WAN-интерфейсе роутера; если WAN-адрес роутера не является публичным, укажите это как есть. Внешне наблюдаемый исходящий IP можно получить через сервисы проверки; указание обоих адресов позволяет быстро определить наличие промежуточного NAT.
Если одновременно используются IPv4 и IPv6, необходимо описать их отдельно. Во многих мобильных сетях или домашних широкополосных подключениях уже включён IPv6, но IPv4 всё ещё может проходить через CGNAT. При описании проблемы не говорите просто «нет доступа», а укажите требуемый входящий протокол, например TCP порт 443 для HTTPS или UDP порт 51820 для WireGuard. Также опишите текущую топологию, например режим оптического модема (мост или маршрутизатор), марку и модель роутера, наличие вторичного роутера.
В заявке не следует требовать от оператора «отбелить» IP из чёрного списка, если нет конкретных доказательств ошибочной пометки адреса. Более уместные вопросы: предоставляет ли текущий тариф публичный IPv4-адрес? Разрешены ли входящие подключения? Если IPv4 недоступен, доступен ли входящий IPv6? Эти вопросы касаются возможностей сети, а не репутации. Конфиденциальные журналы, такие как полные записи трафика или учётные данные доступа, не нужно предоставлять заранее, но если оператору требуется дальнейшая диагностика, можно предоставить обезличенные журналы по принципу минимальной необходимости.
Если оператор запрашивает доказательства, можно составить хронологию: когда была настроена переадресация портов, из какой внешней сети проводилось тестирование, какие инструменты использовались и какие результаты получены. Эти доказательства следует сохранять без изменений, не редактируя скриншоты или выводы. При отслеживании заявки фиксируйте время каждого общения, номер сотрудника поддержки и выводы для формирования проверяемой записи. Чёткое указание желаемого способа решения и сроков следующего шага также повышает эффективность обработки.
Как выбирать домашним пользователям и разработчикам
Домашним пользователям, которым нужен удалённый доступ к самостоятельно управляемым устройствам, следует сначала проверить, поддерживает ли тариф входящий публичный IPv4 или IPv6, а затем выбрать подходящее решение. Если прямой входящий доступ отсутствует, можно рассмотреть аутентифицированный обратный туннель или релейный сервис, проверив управление доступом, способ обслуживания, стоимость и доступность, а также соблюдая правила используемой сети. Необходимость такого решения зависит от целей, и не стоит считать «обязательное наличие публичного IPv4» предпосылкой для любого удалённого доступа.
Относительно публичного IP и доступности портов у домашних пользователей часто встречается заблуждение: считается, что если WAN-адрес роутера публичный, то все порты доступны из интернета. На самом деле многие домашние широкополосные подключения даже при выделении публичного IPv4 блокируют распространённые сервисные порты на пограничном оборудовании оператора. Кроме того, динамический публичный IP может меняться, поэтому для удалённого доступа дополнительно требуется динамический DNS. Если нужен лишь временный доступ, надёжнее использовать удалённое управление от производителя или авторизованный релейный сервис.
Разработчикам при отладке интернет-сервисов нельзя считать успешный исходящий доступ с локальной машины подтверждением входящего доступа из интернета. Успешный исходящий доступ через NAT или брандмауэр означает лишь, что исходящий путь свободен, но не гарантирует, что внешние узлы могут активно подключиться к вашей машине. Например, если веб-сервис работает на localhost и успешно обращается к внешнему API через curl, это не доказывает, что внешние пользователи могут получить доступ к этому веб-сервису. Необходимо провести активное тестирование с другой машины в другой сети или с помощью внешнего инструмента проверки TCP.
Разработчикам также следует проверять публикацию портов между контейнерами, виртуальными машинами и хостом. Нормальная работа сервиса в контейнере не означает, что хост открыл этот порт на ожидаемом интерфейсе; доступность на loopback-адресе хоста не означает доступность из локальной сети или интернета. При финальной приёмке следует указать точку наблюдения и ожидаемый результат: для TCP-сервиса необходимо завершить подключение и ожидаемое взаимодействие, для UDP-сервиса — отправить запрос, соответствующий протоколу, и проверить ответ; нельзя делать вывод об «установленном TCP» на основе UDP без рукопожатия.
Три частых вопроса и ответа
Является ли публичный IP фиксированным? Это зависит от оператора и тарифа. Домашние широкополосные подключения обычно используют динамические адреса: даже при выделении публичного IPv4 он может измениться после истечения аренды, переподключения или перезагрузки устройства. Корпоративные выделенные линии или тарифы с фиксированным IP могут предоставлять статические адреса, но за дополнительную плату. IPv6-адреса обычно назначаются через делегирование префикса; если префикс оператора не меняется, адрес устройства может оставаться стабильным в течение некоторого времени, но постоянство не гарантируется. Не предполагайте, что адрес фиксирован; для удалённых сервисов всё равно требуется динамический DNS или регулярное обновление конфигурации.
Обязательно ли перезагрузка роутера меняет адрес? Не обязательно. Изменение адреса зависит от времени аренды DHCP, политики пула адресов оператора и способа аутентификации. Иногда после перезагрузки адрес не меняется, иногда меняется — общего правила нет. В среде CGNAT перезагрузка может изменить внутреннее сопоставление оператора, а не публичный исходящий адрес. Чтобы определить, изменился ли текущий выход, можно до и после перезагрузки записать исходящий IP с помощью нескольких независимых сервисов проверки, сохраняя неизменными часовой пояс и сетевое окружение.
Совместное использование несколькими пользователями публичного IP-адреса автоматически не означает, что они могут получить доступ друг к другу, и не является доказательством изоляции безопасности. Фактическая изоляция зависит от конфигурации сети доступа, контроля доступа и межсетевых экранов устройств, и NAT нельзя рассматривать как полный периметр безопасности. Общий выход может создавать репутационные ассоциации, из-за чего обычные пользователи вместе сталкиваются с капчами или ограничениями, но конкретное влияние зависит от политик целевых сайтов. Следует оценивать связность, репутацию адреса и безопасность устройств по отдельности, избегая обобщения всех проблем одним ярлыком «общий».
Формирование проверяемой записи
При устранении неполадок с доступностью публичного IP-адреса и порта записи должны поддерживать последующую проверку. При создании временной шкалы используйте схематичный подход: например, в 10:00 настроена переадресация портов на маршрутизаторе, в 10:05 из внешней сети с помощью инструмента проверки TCP тест порта 8443 завершился неудачей; в 10:10 изменён межсетевой экран хоста, в 10:15 повторный тест снова неудачен. Такая запись чётко показывает каждый шаг и результат. Не опускайте неудачные операции, поскольку неудачи также позволяют исключить переменные.
Изменяйте только одну переменную за раз и записывайте результаты до и после, одновременная корректировка правил межсетевого экрана и маршрутизатора затруднит определение причины. Сохраняйте страницы состояния, тексты ошибок, время тестирования и результаты исходящего узла; при предоставлении материалов внешним сторонам удаляйте номера учётных записей, токены и другую нерелевантную информацию. Для понимания типов адресов, источников и границ наблюдения читайте Источники данных и методика на этом сайте. Главное в записи — дать следующему специалисту возможность воспроизвести условия, а не накапливать необъяснимые скриншоты.
Обнаружение общего IP-адреса или прокси может давать ложные срабатывания, например, обычная домашняя сеть из-за общего исходящего узла помечается как VPN или прокси. В таком случае следует собрать исходящий IP-адрес, время запроса и платформу обнаружения, записать различия в оценках нескольких платформ. Не полагайтесь только на один чёрный список или сервис обнаружения, некоторые платформы недружелюбны к диапазонам CGNAT. Соответствующие случаи ложных срабатываний и направления для исследования см. в IP определён как VPN или прокси: как проверить ошибку, где объясняется, как отличить пометку на уровне адреса от фактического поведения прокси.
Если записи об устранении неполадок достаточно полны, но проблема не решена, следует установить чёткие условия остановки. Например: локальное прослушивание и межсетевой экран изменены, правила маршрутизатора подтверждены как корректные, тесты из двух разных внешних сетей завершились неудачей, и оператор связи ответил, что возможность входящих соединений отсутствует. В этом случае следующим шагом должно быть обращение к оператору за публичным адресом или использование авторизованной схемы ретрансляции, а не продолжение догадок или изменений. После завершения заархивируйте все записи, укажите вывод "невозможно установить входящее соединение, причина указывает на политику оператора" и приложите цепочку доказательств.
