UDP Test from Israele

Le verifiche UDP dai nostri nodi israeliani inviano un pacchetto alla porta specificata e aspettano una risposta. Questo è rilevante per testare resolver DNS, endpoint WireGuard o OpenVPN, infrastruttura SIP e server di gioco che devono essere raggiungibili dagli utenti israeliani. L'infrastruttura ISP israeliana non blocca l'UDP in uscita sulle connessioni commerciali, quindi un risultato senza risposta dai nostri nodi indica che il blocco è sul lato della destinazione o in transito e non all'interno di Israele.

Per i servizi VPN o di tunneling con utenti israeliani, una verifica UDP da AS206446 conferma se l'endpoint è raggiungibile da uno dei maggiori ASN di hosting di Israele. Gli endpoint WireGuard non risponderanno a una probe UDP a meno che il peer non sia configurato — un risultato senza risposta è normale per WireGuard correttamente deployato. OpenVPN UDP e i protocolli dei server di gioco che inviano una risposta non autenticata alla probe confermeranno la raggiungibilità restituendo qualsiasi pacchetto.

Eseguire verifiche UDP da entrambi i nodi israeliani simultaneamente è un rapido test di coerenza. Poiché entrambi i nodi condividono lo stesso upstream (AS206446) e percorso di transito internazionale, risultati diversi tra i due verso la stessa destinazione indicherebbero un'anomalia di routing per nodo. Una risposta assente coerente da entrambi conferma che il problema non è specifico del nodo ma è un problema generale del percorso dalle reti israeliane alla destinazione.

L'infrastruttura internet di Israele è concentrata nell'area metropolitana di Tel Aviv, dove si trovano le principali strutture IX del paese, i data center e i carrier hotel. IIX (Israel Internet Exchange) opera la principale fabric di peering, usata dagli ISP domestici, dai provider di content e dai PoP CDN. ISUOG funge da IX secondario. Entrambi sono situati nel corridoio metro di Tel Aviv, dove la maggior parte dell'infrastruttura carrier e di hosting israeliana è fisicamente alloggiata. Petah Tikva e Netanya — le due città che hostano i nostri nodi probe — distano approssimativamente 15 km l'una dall'altra e rientrano entrambe in questa concentrazione metro.

La connettività internazionale da Israele esce quasi interamente via cavi sottomarini. I sistemi di cavi FLAG e SEA-ME-WE attraccano a Haifa e Tel Aviv, fornendo la capacità primaria verso l'Europa attraverso il Mediterraneo. Un percorso secondario corre via terra attraverso l'Egitto tramite il Sinai. Il percorso Tel Aviv-Francoforte impiega approssimativamente 50-60 ms sulla capacità in cavo ben instradata. Tel Aviv-Londra si colloca intorno a 60-68 ms. Tel Aviv-New York è approssimativamente 125-135 ms via cavo transatlantico. Questi RTT sono competitivi con le location del Sud Europa, collocando Israele entro range utile dell'infrastruttura CDN europea.

I maggiori carrier israeliani includono Bezeq International (AS8551), che opera il principale backbone fisso domestico, Partner Communications (AS12400), HOT Telecom (AS5486) e Cellcom. Il mercato ISP e hosting commerciale è servito da provider aggiuntivi tra cui CLOUD LEASE (AS206446), che hosta entrambi i nostri nodi probe. AS206446 è un provider di cloud hosting e colocation con presenza a Petah Tikva e Netanya, entrambi serviti via backbone domestico israeliano con transito successivo verso IIX e gateway internazionali.

Israele ha una delle velocità medie di broadband in linea fissa più alte della regione, guidata dal deployment diffuso di fibra e da prezzi ISP competitivi. Il mercato israeliano è insolitamente ben peerato per la sua posizione geografica — la prossimità all'Europa via cavo sottomarino e la partecipazione attiva a IIX significa che molti edge CDN europei servono Israele con latenza paragonabile a ciò che vedono gli utenti del Sud Europa. Akamai, Cloudflare e AWS mantengono tutti edge PoP nella regione di Tel Aviv.

Operiamo due nodi probe in Israele — uno a Petah Tikva e uno a Netanya — entrambi via CLOUD LEASE (AS206446). Avere due nodi sullo stesso AS e nella stessa area metro significa che i risultati sono tipicamente coerenti, ma eseguirli entrambi simultaneamente conferma che nessuno dei due nodi ha un'anomalia di routing locale. Per le destinazioni con Anycast o GeoDNS, entrambi i nodi dovrebbero restituire risultati identici o quasi identici data la loro prossimità geografica e l'upstream condiviso.