UDP-проверки с наших израильских узлов отправляют пакет на указанный порт и ожидают ответа. Это актуально для тестирования DNS-резолверов, конечных точек WireGuard или OpenVPN, SIP-инфраструктуры и игровых серверов, которые должны быть доступны от израильских пользователей. Инфраструктура израильских провайдеров не блокирует исходящий UDP на коммерческих соединениях, поэтому отсутствие ответа с наших узлов указывает на блокировку на стороне цели или в транзите, а не внутри Израиля.

Для VPN или туннелирующих сервисов с израильскими пользователями UDP-проверка с AS206446 подтверждает, доступна ли конечная точка из одного из основных хостинговых ASN Израиля. Конечные точки WireGuard не будут отвечать на UDP-зонд, если пир не настроен — отсутствие ответа нормально для корректно развёрнутого WireGuard. OpenVPN UDP и протоколы игровых серверов, которые отправляют неаутентифицированный ответ на зонд, подтвердят доступность, вернув любой пакет.

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

Интернет-инфраструктура Израиля сконцентрирована в столичном районе Тель-Авива, где расположены основные IXP-объекты страны, дата-центры и операторские узлы. IIX (Israel Internet Exchange) управляет основной пиринговой инфраструктурой, используемой внутренними провайдерами, контент-провайдерами и CDN-PoP. ISUOG служит вторичной точкой обмена трафиком. Обе расположены в коридоре столичного района Тель-Авива, где физически размещена большая часть израильской операторской и хостинговой инфраструктуры. Петах-Тиква и Нетания — два города, в которых расположены наши узлы-зонды — находятся примерно в 15 км друг от друга и оба попадают в эту столичную концентрацию.

Международная связность из Израиля выходит практически исключительно через подводные кабели. Кабельные системы FLAG и SEA-ME-WE выходят на берег в Хайфе и Тель-Авиве, обеспечивая основную ёмкость в направлении Европы через Средиземное море. Вторичный путь проходит по суше через Египет через Синайский полуостров. Путь Тель-Авив–Франкфурт занимает около 50–60 мс на хорошо маршрутизированной кабельной ёмкости. Тель-Авив–Лондон — около 60–68 мс. Тель-Авив–Нью-Йорк — около 125–135 мс через трансатлантический кабель. Эти RTT конкурентоспособны с южноевропейскими локациями, помещая Израиль в пределах полезного диапазона европейской CDN-инфраструктуры.

Крупные израильские операторы включают Bezeq International (AS8551), управляющий основной внутренней фиксированной магистралью, Partner Communications (AS12400), HOT Telecom (AS5486) и Cellcom. Коммерческий рынок провайдеров и хостинга обслуживается дополнительными провайдерами, включая CLOUD LEASE (AS206446), который является хостом обоих наших узлов-зондов. AS206446 — поставщик облачного хостинга и колокации с присутствием в Петах-Tikve и Нетании, оба обслуживаются через израильскую внутреннюю магистраль с транзитом к IIX и международным шлюзам.

Израиль имеет один из самых высоких средних скоростей фиксированного широкополосного доступа в регионе, обусловленный широким развёртыванием оптоволокна и конкурентными ценами на провайдерские услуги. Израильский рынок необычно хорошо связан для своего географического положения — близость к Европе через подводный кабель и активное участие в IIX означает, что многие европейские CDN-edge обслуживают Израиль с задержкой, сопоставимой с тем, что видят южноевропейские пользователи. Akamai, Cloudflare и AWS поддерживают edge-PoP в районе Тель-Авива.

Мы управляем двумя узлами-зондами в Израиле — одним в Петах-Tikve и одним в Нетании — оба через CLOUD LEASE (AS206446). Наличие двух узлов в одном AS и столичном районе означает, что результаты обычно согласованны, однако одновременный запуск обоих подтверждает, что ни один из узлов не имеет локальной аномалии маршрутизации. Для целей с Anycast или GeoDNS оба узла должны возвращать идентичные или близкоидентичные результаты, учитывая их географическую близость и общий аплинк.