Роскачество поясняет, как можно вычислить местоположение пользователя по IP
Главная » Архив » Новости » Технологии » Роскачество поясняет, как можно вычислить местоположение пользователя по IP
21.06.2022, 15:22
31
Фото: Depositphotos
Как у большинства людей есть адрес по месту жительства, так и у всех владельцев Интернет-устройств есть IP-адрес. Что это такое, какова его роль в определении личности пользователя и что будет, если его узнают, поясняют специалисты Центра цифровой экспертизы Роскачества.
Английская аббревиатура IP (Internet Protocol) расшифровывается как межсетевой протокол. IP‑адрес служит для связи: на него отправляются электронные письма, запросы сайтов и прочая информация при выходе пользователя в Сеть.
Что такое цифровые финансовые активы (ЦФА)
Этот уникальный идентификатор есть у любого подключенного к Интернету устройства.
IP‑адреса бывают статическими (постоянными) и динамическими (меняется при каждом подключении). Ещё используют понятия белый и серый IP. Белый — это персональный адрес, а серый — общий, через него в Сеть выходят несколько пользователей (например, в одной организации или доме).
Обычным пользователям провайдеры выдают серые динамические адреса. Статические и белые понадобятся при создании веб-сайта и оформляются за отдельную плату. Следовательно, определить местоположение пользователя с серым динамическим адресом почти невозможно.
«Да я тебя по IP вычислю!»
К примеру, человек отправил вам электронное письмо. Теперь его IP‑адрес можно найти через расширенную информацию в сообщении. Другой способ — отследить цепочку подключений с помощью специального сервиса.
Согласитесь, в повседневной жизни вряд ли кто-то будет настолько усердствовать, чтобы узнать ваш IP.
Если кто-то узнал ваш IPЧто он может сделать с этой информацией? На самом деле, немногое. Обычный человек по адресу IP максимум может посмотреть название вашего провайдера, страну и город, откуда вы выходили в Интернет.
Однако по запросу полиции, следственного комитета или ФСБ, провайдер предоставит точное место, откуда вы выходили в Сеть. Сотрудники интернет-компании обязаны будут уточнить, какой адрес был присвоен устройству пользователя в обозначенный отрезок времени. И это сработает даже в случае с динамическим IP. А если быть точнее, у провайдеров записи идут не по IP, а по MAC-адресам сетевой карты.
Таким образом, адрес IP характеризует не отдельное устройство, а одно сетевое соединение. Поэтому если кто-то его и вычислит, найти вас вряд ли сможет.
Рубрика:
{}Технологии
Теги:
#IP-АДРЕС
#РОСКАЧЕСТВО
Идеального API «Город по IP» не существует. Наше — хорошее — Блог Dadata.ru
У «Дадаты» есть фича «Город по IP» — ее часто используют, например, интернет-магазины.
По IP определяют, где живет посетитель сайта. Если город известен, клиенту можно сразу показать стоимость доставки или скорректировать список доступных товаров.
Порой нам пишут пользователи и сетуют: мол, у вас в «Адресе по айпи» ошибки. Не тот город.
Весточка из числа тех, что мы иногда получаемПроблема действительно существует: «Дадата» определяет населенный пункт по IP с точностью 60-80%. В статье я расскажу, почему определить город по айпи так сложно, откуда берутся промахи и есть ли в природе идеальное решение.
Спойлер: увы, полностью от ошибок не избавиться. Это не проблема «Дадаты» как сервиса, а принципиальная особенность технологии.
Как «Дадата» определяет город по IP
Собирать и обновлять все IP-адреса страны с привязкой к городам — колоссальная задача. Ее потянут разве что гиганты вроде «Яндекса». Поэтому на старте мы взяли один из сторонних справочников, где IP сопоставлены населенным пунктам.
Подобные базы данных собирают и продают специальные провайдеры. Иногда отдают по бесплатным лицензиям. Провайдеров немало, навскидку назову около десятка. Делая «Дадату», мы вложили в тестирование справочников много сил.
В свое время проверили справочники IPGeoBase, SypexGEO, MaxMind Lite, ip2ruscity, 2ip.ru и другие. Тестировали полноту, частоту обновлений, формат данных, детализацию. По итогам выложили на «Хабре» подробный обзор.
Мы выбрали самый точный справочник городов и IP из всех, что удалось найти — IPGeoBase. Но все еще были недовольны ошибками.
Поэтому в 2018 году перешли на данные RIPE NCC.
RIPE хорош тем, что эти ребята своими руками назначают IP-адреса интернет-провайдерам. Поэтому дают самый актуальный справочник с указанием, какой диапазон IP кому принадлежит.
Мы очистили данные RIPE от колоссального количества ошибок. Затем подружили с российской адресной системой ФИАС. В итоге «Дадата» не просто отдает привязку IP к городу. Внутри:
- названия и типы найденных объектов и всех родителей;
- признаки центра региона;
- индексы населенных пунктов;
- ФИАС- и КЛАДР-коды регионов и городов;
- ISO-коды регионов;
- и еще множество данных. Весь список — в документации.
«Дадата» полнее и точнее, чем любой «голый» справочник. Во-первых, мы отдаем больше информации. Во-вторых, каждый месяц исправляем ошибки. В-третьих, забираем новые данные у RIPE, не приходится делать это вручную. Наконец, проще получать данные по API, чем писать интерфейс доступа к справочнику.
Казалось бы, проблема решена: RIPE предоставляет идеальный справочник «город по IP», а «Дадата» насыщает его данными.
Увы, проблему неправильно найденных городов не решить даже так.
Почему поиск по IP показывает другой город
Поиск города неточен, потому что так устроен сам алгоритм назначения IP-адресов. Технологически IP не привязаны к географии и спокойно гуляют между населенными пунктами. Кроме того, «айпишники» постоянно переезжают от одних региональных подразделений провайдеров к другим.
Например, RIPE назначил диапазон IP провайдеру из Екатеринбурга. А тот по своему усмотрению раздает адреса всем городам Урала. RIPE об этом ничего не узнает.
Об изменениях в географии IP никто не сообщает, поэтому и сервисы, и составители справочников ошибаются. За жизнью не успевают даже те их них, что обновляются раз в неделю.
В любом справочнике хватает ошибок, даже у гигантов. При этом недочеты отличаются, потому что разные сервисы и провайдеры обновляют данные с разной частотой. А еще по-разному пытаются повысить точность поиска. Из-за этого порой кажется, что чужой справочник лучше своего.
Типичный кейс: пользователь видит, что «Дадата» неправильно определяет город для конкретного айпи. А условный справочник 2ip этот же IP трактует как надо.
Пользователь переключается на 2ip, но через неделю обнаруживает, что ситуация не улучшилась. Просто раньше «Город по IP» ошибался с одними адресами, а теперь — с другими. Мы сталкивались с этим неоднократно, в том числе когда сами выбирали справочник для «Дадаты».
На деле, если используешь известный и авторитетный справочник, менять его бессмысленно. Увы, метод «Город по IP» будет порой ошибаться, даже если сменить «Дадату» на любой другой сервис.
Как повысить точность поиска прямо сейчас
Единственный способ точнее определять город — использовать альтернативные методы.
Если речь о мобильном приложении, можно получать координаты с GPS-датчика. Но тогда проблема с точностью, скорее всего, и не возникла бы. Если есть координаты, зачем искать город по IP.
Альтернатива для интернет-сервисов и сайтов — запрашивать координаты браузера с помощью HTML5 Geolocation API.
Правда, у метода есть проблема: пользователь должен дать осознанное согласие на передачу координат.
Мы не знаем, станет ли лучше, если вместо IP определять город по координатам браузера. Для стационарных компьютеров этот метод столь же неточен, потому что GPS-датчики и вышки сотовой связи недоступны. Но есть проблемы и посерьезнее:
- всплывающие окна всех раздражают;
- люди не любят раскрывать местоположение, когда их прямо об этом спрашивают. Скорее отказываются.
Можно внедрить гибридную модель: для начала запрашивать координаты браузера. А если пользователь отказывает, определять город по IP.
А как у вас дела с поиском города по IP? Напишите в комментариях, какими сервисами и справочниками пользуетесь. Нашли ли решение, которое работает лучше других?
IP-адресов | LMi.net
Каждому компьютеру, подключенному к Интернету, должен быть присвоен IP-адрес.
IP-адреса определяют, где находится компьютер в Интернете, чтобы веб-серверы и почтовые серверы могли отправлять данные на нужный компьютер. IP -адрес представляет собой серию из четырех чисел, разделенных точками:
66.117.136.6
208.25.127.254
192.168.1.1
Государственный и частный IP -адрес . Общедоступные IP-адреса используются маршрутизаторами и компьютерами, подключенными напрямую к DSL-модемам без маршрутизатора. Частные IP-адреса — это специальные IP-адреса, которые известны только маршрутизатору и его домашней сети. Веб-сервер не будет доставлять интернет-данные на частный IP-адрес. Он доставляет данные на маршрутизатор (который имеет общедоступный IP-адрес), а затем маршрутизатор доставляет данные на компьютер с частным IP-адресом.
Маршрутизаторы особенные, потому что они имеют два IP-адреса. IP-адрес назначается каждому из двух «интерфейсов» маршрутизатора. Первый интерфейс маршрутизатора называется интерфейсом WAN (Wide Area Network).
ДИНАМИЧЕСКОЕ НАЗНАЧЕНИЕ IP-АДРЕСОВ КОМПЬЮТЕРАМ
Одной из основных задач маршрутизатора является назначение IP-адресов компьютерам в домашней сети. Маршрутизатор имеет «пул» IP-адресов, которые он отслеживает. Когда компьютер подключается к нему и запрашивает IP-адрес, маршрутизатор выбирает IP-адрес из пула и назначает его компьютеру. Маршрутизатор следит за тем, чтобы двум компьютерам не был назначен один и тот же IP-адрес. Этот процесс, когда компьютеры запрашивают IP-адрес у маршрутизатора, называется «динамическим» присвоением IP-адреса. Он использует сетевой протокол под названием DHCP (протокол динамической конфигурации хоста).
После того, как компьютер использовал IP-адрес и отключился от маршрутизатора, этот адрес можно вернуть в пул доступных IP-адресов.
СТАТИЧЕСКИЕ IP-АДРЕСА
Противоположностью динамически назначаемого IP-адреса является статический IP-адрес. Статический IP-адрес необходимо настроить вручную на устройстве, которое будет его использовать. Если вы подключаете только один компьютер к вашему DSL-модему, он будет использовать статический IP-адрес, предоставляемый вашей услугой DSL (пожалуйста, см. лист с инструкциями в вашем комплекте DSL, для которого был назначен IP-адрес). Вы настроите свой компьютер на использование этого IP-адреса, пока у вас есть служба DSL.
Эта настройка влияет на безопасность. Если у вас есть статический IP-адрес и у вас нет устройства под названием «брандмауэр», ваш компьютер более уязвим для хакеров. Брандмауэр проверяет интернет-трафик и решает, является ли трафик хорошим или плохим. Он может защитить ваш компьютер от опасного интернет-трафика и хакеров. Рекомендуется использовать маршрутизатор, даже если вы хотите подключить к Интернету только один компьютер, потому что маршрутизатор будет иметь встроенный брандмауэр.
Маршрутизатор обычно использует статический IP-адрес для своего интерфейса WAN (сторона маршрутизатора, обращенная к Интернету). Это означает, что маршрутизатор должен быть настроен вручную с этим адресом. Это то, что LMi.net может сделать для вас, или вы можете сделать это сами. Настройка статического IP-адреса на маршрутизаторе занимает всего несколько минут.
конечных точек и IP-адресов WireGuard
При начале работы с WireGuard может быть сложно понять взаимодействие между сетевыми уровнями ниже WireGuard («настоящая» сеть, часто физическая сеть Ethernet или WiFi) и WireGuard VPN (виртуальная частная сеть). В этой статье будет рассказано о том, какие параметры конфигурации для каких («настоящая» сеть или виртуальная сеть используются), и будет отслеживаться, как отдельный пакет проходит между ними.
Если вас интересует терминология, используемая в этой статье, ознакомьтесь со статьей WireGuard Terminology для уточнения.
Настройки IP-адреса
Давайте сначала рассмотрим простой файл конфигурации WireGuard. Здесь вы увидите три разных параметра с IP-адресами — Address, AllowedIPs и Endpoint:
. # /etc/wireguard/wg0.conf [Интерфейс] PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE= Адрес = 10.0.0.1/32 Порт прослушивания = 51821 [Вглядеться] Публичный ключ = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds= Разрешенные IP-адреса = 192.168.200.0/24 Конечная точка = 203.0.113.2:51822
168.200.0/24
Конечная точка = 203.0.113.2:51822
Адрес
Параметр Address — это виртуальный адрес локального узла WireGuard. Это IP-адрес виртуального сетевого интерфейса, который WireGuard устанавливает для узла; и поэтому вы можете установить его на все, что хотите (все, что имеет смысл для виртуальной сети WireGuard, которую вы строите).
Как и в случае с другими сетевыми интерфейсами, IP-адрес интерфейса WireGuard определяется префиксом сети, который сообщает локальному хосту, какие другие IP-адреса доступны в той же виртуальной подсети, что и интерфейс. В приведенном выше примере этот префикс — /32 (обычно это безопасное значение по умолчанию для интерфейса WireGuard). Если мы установим его в /24, это укажет локальному хосту, что другие адреса в том же блоке /24, что и сам адрес (от 10.0.0.0 до 10.0.0.255), маршрутизируются через интерфейс.
AllowedIPs
Но WireGuard не использует этот сетевой префикс для управления тем, что на самом деле маршрутизируется через интерфейс — вместо этого WireGuard полагается на настройку 
WireGuard отбрасывает любой трафик, направленный на интерфейс, адрес назначения которого находится за пределами разрешенных IP-адресов, настроенных для одноранговых узлов интерфейса, а также отбрасывает любой трафик, поступающий на хост через интерфейс, исходный адрес которого находится за пределами тех же разрешенных IP-адресов.
Если вы используете программу wg-quick (или приложение WireGuard на таких платформах, как iOS, Android и т. д.) для настройки интерфейса WireGuard, эта программа также настроит таблицу маршрутизации хоста с маршрутами, соответствующими настройке AllowedIPs, чтобы трафик, который может направляться на интерфейс WireGuard , будет направляться на него.
Если вы хотите направить весь трафик хоста через интерфейс WireGuard, вы должны настроить интерфейс с одним узлом и установить для него AllowedIPs 0.0.0.0/0, ::/0. Однако в приведенном выше примере мы хотим направить только определенную подсеть на интерфейс WireGuard — конкретный внутренний сайт, к которому мы хотим иметь доступ через туннель WireGuard, к узлу, расположенному на сайте — поэтому мы устанавливаем AllowedIPs для сверстник до 192.
168.200.0/24 (блок адресов с 192.168.200.0 по 192.168.200.255).
Если бы мы также хотели, чтобы этот интерфейс мог маршрутизироваться в подсеть 10.0.0.0/24, независимо от того, что мы установили для настройки адреса интерфейса, нам пришлось бы явно добавить эту подсеть в настройку AllowedIPs для одного из аналоги интерфейса. (Или, что более вероятно, примените разные блоки подсети к настройке AllowedIPs разных пиров, если интерфейс имеет несколько пиров.)
Обратите внимание, что вы можете указать несколько IP-адресов (или блоков адресов), либо разделив их запятыми в индивидуальную настройку AllowedIPs, или вы можете просто указать настройку AllowedIPs несколько раз для одного и того же узла:
[Вглядеться] Публичный ключ = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds= Разрешенные IP-адреса = 192.168.200.0/24, 10.0.0.0/24 # или альтернативно: Разрешенные IP-адреса = 192.168.200.0/24 Разрешенные IP-адреса = 10.0.0.0/24
Как видите, IP-адреса, указанные параметром AllowedIPs, могут представлять собой сочетание «реальных» адресов (например, «настоящая» удаленная подсеть) и виртуальных адресов (например, других адресов в вашей сети WireGuard VPN).
Конечная точка
Когда трафик направляется на виртуальный интерфейс WireGuard, WireGuard необходимо знать, куда направить этот трафик в «реальной» сети. Настройка конечной точки для каждого узла сообщает WireGuard «настоящий» IP-адрес и порт, на который он в конечном итоге должен отправлять трафик.
В приведенном выше исходном примере одноранговый узел, указанный для интерфейса, имеет настройку AllowedIPs 192.168.200.0/24 и настройку конечной точки 203.0.113.2:51822. Это означает, что для любого трафика, направляемого на интерфейс в пределах IP-адреса в диапазоне от 192.168.200.0 до 192.168.200.255, WireGuard будет шифровать и перенаправлять трафик через «настоящий» сетевой интерфейс на «настоящий» удаленный адрес 203.0.0. 113.2 (на UDP-порту 51822).
Обратите внимание, что вам нужно настроить статическую конечную точку только на одной стороне соединения WireGuard. Если на узле A мы настроим параметр конечной точки для узла B, мы можем пропустить настройку параметра конечной точки на узле B для узла A — узел B будет ждать, пока узел A подключится к нему, а затем динамически обновит свой параметр конечной точки до фактического IP-адрес и порт, с которого подключился Peer A.
Поток пакетов
Теперь давайте рассмотрим конкретный пример, в котором мы отслеживаем поток пакетов от одной конечной точки сети к другой и обратно. Мы будем использовать топологию «точка-сайт», где у нас есть «конечная точка A», планшет конечного пользователя с WireGuard, подключенный к «Host Beta», также работающий с WireGuard и выступающий в качестве маршрутизатора для «сайта B». На сайте B у нас будет «Конечная точка B», HTTP-сервер, на который конечная точка A попытается отправить некоторый трафик.
На приведенной ниже диаграмме показан этот сценарий:
Сценарий «точка-сеть» (от конечной точки A к сайту B)Конфигурация для этого сценария описана в статье «Конфигурация точки-сайта». Это параметры конфигурации WireGuard, которые мы использовали бы для конечной точки A:
. # локальные настройки для конечной точки А [Интерфейс] PrivateKey = AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEE= Адрес = 10.0.0.1/32 Порт прослушивания = 51821 # удаленные настройки для Host β [Вглядеться] Публичный ключ = fE/wdxzl0klVp/IR8UcaoGUMjqaWi3jAd7KzHKFS6Ds= Разрешенные IP-адреса = 192.
168.200.0/24
Конечная точка = 203.0.113.2:51822
И параметры конфигурации, которые мы будем использовать для бета-версии хоста:
# локальные настройки для Host β [Интерфейс] PrivateKey = ABBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBFA= Адрес = 10.0.0.2/32 Порт прослушивания = 51822 # IP-переадресация PreUp = sysctl -w net.ipv4.ip_forward=1 # Маскарадинг IP (источник NAT) PreUp = iptables -t mangle -A PREROUTING -i wg0 -j MARK --set-mark 0x30 PreUp = iptables -t nat -A РАЗМЕЩЕНИЕ ! -o wg0 -m отметка --mark 0x30 -j МАСКАРАД PostDown = iptables -t mangle -D PREROUTING -i wg0 -j MARK --set-mark 0x30 PostDown = iptables -t nat -D ОТПРАВКА ! -o wg0 -m отметка --mark 0x30 -j МАСКАРАД # удаленные настройки для конечной точки А [Вглядеться] Открытый ключ = /TOE4TKtAqVsePRVR+5AA43HkAK5DSntkOCO7nYq5xU= Разрешенные IP-адреса = 10.0.0.1/32
Конечная точка A
Конечная точка A имеет сетевой интерфейс WiFi с именем wlan0 и IP-адресом 192.168.1.11; и интерфейс WireGuard с именем wg0 и IP-адресом 10.
0.0.1 (интерфейс WireGuard показан в приведенной выше конфигурации).
Для начала, на конечной точке A пользователь переходит по адресу http://192.168.200.22/ в веб-браузере (192.168.200.22 — это IP-адрес конечной точки B на сайте B). уровень API, чтобы попытаться открыть сокет TCP на порт 80 из 192.168.200.22. Сетевой стек ОС (операционной системы), работающей на конечной точке А, реализует это частично, отправив несколько TCP-пакетов (первый из которых мы проследим).
Однако перед отправкой каких-либо пакетов ОС конечной точки A проверит свои таблицы маршрутизации, чтобы определить, к какому локальному сетевому интерфейсу привязать новый сокет TCP. Поскольку мы настроили параметр AllowedIPs на интерфейсе wg0 конечной точки A на 192.168.200.0/24 (и использовали wg-quick для управления этим интерфейсом), WireGuard добавил запись в таблицу маршрутизации конечной точки A, которая указывает использовать wg0 для подключения к 192.168.200.0/24 блок адресов.
Следовательно, поскольку предполагается подключение к 192.
168.200.22, конечная точка A выберет wg0 в качестве интерфейса для этого TCP-сокета и будет использовать IP-адрес интерфейса wg0 10.0.0.1 в качестве исходного адреса сокета. В качестве исходного порта будет выбран случайный неиспользуемый порт 10.0.0.1; в нашем случае, скажем, он выбирает порт 50000.
Затем, чтобы инициировать этот сокет TCP, ОС на конечной точке A сгенерирует пакет SYN TCP и поставит его в очередь на своем интерфейсе wg0:
| Шаг | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 1 | Конечная точка А | WG0 | из | ПТС | 10.0.0.1 | 50000 | 192.168.200.22 | 80 | СИН |
Когда интерфейс wg0 на конечной точке A извлечет этот пакет из своей очереди, он проверит свою таблицу настроенных одноранговых узлов, чтобы увидеть, какой из одноранговых узлов, если таковой имеется, имеет настройку AllowedIPs, которая включает адрес назначения пакета 192.
168.200.22. В нашем случае у нас настроен только один пир для интерфейса, и его настройка AllowedIPs совпадает. Таким образом, WireGuard зашифрует исходный TCP-пакет с помощью открытого ключа однорангового узла и поместит его в новый UDP-пакет, который использует настройку конечной точки однорангового узла в качестве адреса назначения и порта нового пакета (203.0.113.2:51822).
WireGuard также будет использовать таблицы маршрутизации хоста, чтобы определить, какой сетевой интерфейс и IP-адрес использовать для отправки этого нового UDP-пакета. В нашем случае единственным «настоящим» сетевым интерфейсом конечной точки А является wlan0, поэтому он будет использовать этот интерфейс для отправки пакета; и он будет использовать единственный IP-адрес интерфейса wlan0, 192.168.1.11, в качестве адреса источника пакета. В качестве исходного порта будет использоваться параметр конфигурации ListenPort интерфейса wg0 (51821, как показано в приведенной выше конфигурации):
| Шаг | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 2 | Конечная точка А | wlan0 | из | УДП | 192. 168.1.11 | 51821 | 203.0.113.2 | 51822 | зашифрованные данные |
Маршрутизатор NAT
Пакет UDP будет направлен на маршрутизатор NAT (преобразование сетевых адресов) перед конечной точкой A, где маршрутизатор преобразует исходный адрес пакета в собственный общедоступный IP-адрес маршрутизатора. , а также измените исходный порт на тот, который маршрутизатор запомнит как связанный с конечной точкой A. В нашем примере этот IP-адрес — 198.51.100.1, и мы скажем, что порт будет 51111:9.0003
| Шаг | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 3 | Сайт A NAT-маршрутизатор | wlan0 | в | УДП | 192. 168.1.11 | 51821 | 203.0.113.2 | 51822 | зашифрованные данные |
| 4 | Сайт A NAT-маршрутизатор | эт0 | из | УДП | 198.51.100.1 | 51111 | 203.0.113.2 | 51822 | зашифрованные данные |
Затем маршрутизатор NAT отправит пакет в Интернет, откуда он в конечном итоге попадет на хост Beta.
Хост B
Хост Beta имеет два сетевых интерфейса Ethernet, eth0, с IP-адресом 203.0.113.2, подключенных к Интернету; и eth2 с IP-адресом 192.168.200.2, подключенный к локальной сети сайта B (локальная сеть). Он также имеет интерфейс WireGuard с именем wg0 и IP-адресом 10.0.0.2 (как показано в конфигурации в верхней части этого раздела потока пакетов). Он также настроен на NAT для любого входящего трафика, который он получает на свой интерфейс wg0.
Обратите внимание, что NAT для этого интерфейса wg0 противоположен способу, которым трафик сайта B обычно передается в Интернет через NAT.
Обычно исходящий трафик с сайта B в Интернет будет подвергаться NAT для перезаписи исходного адреса всех пакетов, исходящих с сайта B, для использования внешнего адреса его интернет-шлюза (и перезаписи адреса назначения пакетов, возвращающихся на сайт B в ответ). Но для wg0 мы рассматриваем WireGuard VPN как «локальный сайт» и вместо этого используем NAT для исходящего от него трафика на сайт B. Это необходимо, если хосты на сайте B иначе не знали бы, как маршрутизировать трафик для WireGuard VPN. через Host Beta — но в этом нет необходимости.
Таким образом, наш UDP-пакет, исходящий из конечной точки A (через NAT-маршрутизатор на сайте A и через Интернет), попадет на хост Beta на eth0:
| Шаг | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 5 | Хост-бета | эт0 | в | УДП | 198. 51.100.1 | 51111 | 203.0.113.2 | 51822 | зашифрованные данные |
В соответствии с настройкой ListenPort интерфейса wg0 WireGuard будет прослушивать UDP-порт 51822 всех сетевых интерфейсов Host Beta на наличие таких пакетов. WireGuard расшифрует данные из этого пакета, и любые пакеты, которые он обнаружит в расшифрованных данных, будет повторно поставлен в очередь в сетевом стеке хоста, как если бы они пришли непосредственно из интерфейса wg0 на хосте Beta:
| Шаг | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 6 | Хост-бета | WG0 | в | ПТС | 10. 0.0.1 | 50000 | 192.168.200.22 | 80 | СИН |
ОС на хосте Beta проверит свои таблицы маршрутизации и увидит, что пакет, предназначенный для 192.168.200.22, должен быть перенаправлен через сетевой интерфейс eth2. А поскольку хост Beta также настроен на трафик NAT, исходящий от wg0, он преобразует исходный адрес пакета в IP-адрес, используемый для eth2 (192.168.200.2), и выбирает случайный порт для сопоставления с исходным исходным адресом (скажем, 52222):
| Шаг | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 7 | Хост-бета | эт2 | из | ПТС | 192. 168.200.2 | 52222 | 192.168.200.22 | 80 | СИН |
Конечная точка B
Конечная точка B имеет сетевой интерфейс Ethernet с именем eth0 и IP-адресом 192.168.200.22. У него есть HTTP-сервер, прослушивающий TCP-порт 80 этого интерфейса, поэтому он принимает пакет TCP SYN, когда он получает его от хоста Beta:
| 29 Шаг 9 | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 8 | Конечная точка Б | эт0 | в | ПТС | 192.168.200.2 | 52222 | 192.168.200.22 | 80 | СИН |
В ответ он генерирует пакет SYN-ACK, который меняет местами источник и пункт назначения исходного пакета SYN, и отправляет этот пакет на хост Beta:
| Шаг | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 9 | Конечная точка Б | эт0 | из | ПТС | 192. 168.200.22 | 80 | 192.168.200.2 | 52222 | СИН-АКК |
Host B Return
Host Beta receives this SYN-ACK packet, and sees that it’s sent to a port (52222) that it had recently used for NAT:
| Ступенька | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 10 | Хост-бета | эт2 | в | ПТС | 192.168.200.22 | 80 | 192.168.200.2 | 52222 | СИН-АКК |
Итак, он ищет этот порт в своих таблицах NAT и преобразует адрес назначения обратно в 10.0.0.1, а порт назначения обратно в 50000.
Он проверяет свои таблицы маршрутизации на наличие 10.0.0.1 и видит, что он должен быть маршрутизировал свой интерфейс wg0, поэтому он ставит пакет в очередь для выхода из этого интерфейса:
| Шаг | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 11 | Хост-бета | WG0 | из | ПТС | 192.168.200.22 | 80 | 10.0.0.1 | 50000 | СИН-АКК |
Когда интерфейс wg0 извлекает пакет из своей очереди, WireGuard проверит свою таблицу настроенных одноранговых узлов, чтобы увидеть, какой из одноранговых узлов имеет настройку AllowedIPs, включающую адрес назначения пакета 10.
0.0.1. Одноранговый узел, настроенный для конечной точки A, с параметром AllowedIPs 10.0.0.1/32 соответствует; поэтому WireGuard зашифрует пакет с помощью открытого ключа для конечной точки A.
Поскольку ни одна конечная точка не настроена на хосте Beta для конечной точки A, WireGuard будет использовать IP-адрес и порт из последнего пакета, полученного от конечной точки A. что было 198.51.100.1, порт 51111. Таблицы маршрутизации на хосте Beta указывают использовать eth0 для отправки трафика на 198.51.100.1 и использовать с ним исходный IP-адрес 203.0.113.2. И параметр конфигурации ListenPort для wg0 указывает ему использовать порт 51822 в качестве источника своего трафика.
Таким образом, WireGuard поставит в очередь новый пакет UDP, который должен быть отправлен хостом Beta через интерфейс eth0 на адрес 198.51.100.1, содержащий зашифрованный пакет SYN-ACK:0118
0.113.2Возврат маршрутизатора NAT
Маршрутизатор NAT перед конечной точкой A получит этот пакет UDP от хоста Beta через свой общедоступный сетевой интерфейс и распознает порт назначения как порт, который он недавно использовал для NAT. Он преобразует адрес и порт назначения обратно в исходные адрес и порт, используемые конечной точкой А, и пересылает пакет в конечную точку А через интерфейс локальной сети маршрутизатора:
| Шаг | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 13 | Сайт A NAT-маршрутизатор | эт0 | в | УДП | 203. 0.113.2 | 51822 | 198.51.100.1 | 51111 | зашифрованные данные |
| 14 | Сайт A NAT-маршрутизатор | wlan0 | из | УДП | 203.0.113.2 | 51822 | 192.168.1.11 | 51821 | зашифрованные данные |
Endpoint A Return
Endpoint A receives the UDP packet from the NAT router on its wlan0 interface:
| Step | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 15 | Конечная точка А | wlan0 | в | УДП | 203.0.113.2 | 51822 | 192. 168.1.11 | 51821 | зашифрованные данные |
А поскольку параметр ListenPort интерфейса wg0 конечной точки A равен 51821, WireGuard будет прослушивать этот пакет и расшифровывать его. Поскольку он содержит TCP-пакет, и исходный адрес этого TCP-пакета соответствует параметру AllowedIPs для удаленного узла, от которого он был получен, WireGuard повторно поставит в очередь этот расшифрованный TCP-пакет на интерфейсе wg0 конечной точки A:
| Шаг | Хост | Интерфейс | Направление | Протокол | Источник | Порт | Пункт назначения | Порт | Содержание |
|---|---|---|---|---|---|---|---|---|---|
| 16 | Конечная точка А | WG0 | в | ПТС | 192.168.200.22 | 80 | 10. 0.0.1 | 50000 | СИН-АКК |
Поскольку ОС конечной точки A находилась в процессе открытия TCP-сокета на локальном порту 50000 интерфейса wg0, она обрабатывает пакет, видит, что он содержит ожидаемый SYN-ACK, и завершает подтверждение TCP, отправляя новый Пакет TCP ACK возвращается к конечной точке B.
Этот пакет ACK следует тому же точному потоку, что и исходный пакет SYN. После его отправки сокет TCP был установлен, и ОС в конечной точке A возвращает вновь установленный сокет веб-браузеру из исходного вызова API, сделанного браузером. Теперь браузер может отправлять в этот сокет поток данных, который ОС будет упаковывать в TCP-пакеты и отправлять в конечную точку B. Эти пакеты также будут следовать тому же потоку, что и исходный пакет SYN.
Туда-обратно
В завершение, вот схема полной двусторонней передачи пакета SYN и ответа SYN-ACK, описанная выше:
Круговая поездка пакета WireGuardИ объединенные шаги в одной таблице:
0.0.1
0.0.1