Ti sembrerà assurdo ma hai provato a dare curl sul dominio di SDI e vedere se ti da timeout o risponde con una pagina di errore?
Se curl va in timeout prova a dare lo stesso comando dal tuo PC e vedi se funziona (pagina di errore)
Se il tuo PC non da timeout congratulazioni, hai vinto la lotteria e il tuo IP e stato blacklistato da sogei e anche se li contatti direttamente non ammetteranno mai che lo stanno facendo.
A noi è successo e dopo aver implorato per una settimana di fila di verificare a cui prima hanno negato l’evidenza e poi ci hanno ignorato direttamente ci siamo arresi e abbiamo messo in piedi un proxy su cui dirottare le chiamate per aggirare il filtro
Penso sia successo proprio questo, il traceroute, il wget e il curl vanno tutti in errore, da un altro server nella stessa infrastruttura invece funziona tutto correttamente…
Vediamo come si evolve il ticket che abbiamo aperto ieri.
Dalle verifiche che abbiamo fatto la comunicazione si interrompe qua:
Spero che ti rispondano seriamente perché a noi ci hanno trattato veramente di merda e scaricato la responsabilità su di noi nonostante avessimo mostrato le prove che si trattava di un problema a lato loro
Siamo andati pure a scomodare il supporto Linode che ci ha confermato che 3 dei loro datacenter erano filtrati a tavolino
Probabilmente hanno filtrato un range di IP per chissà quale motivo
Confermo che anche nel mio caso il traceroute si ferma su quel preciso host Fastweb… forse sono loro a bloccare le connessioni
La linode non è la società di cloud/service che è stata chiusa a inizio 2023 per i continui attacchi ddos ed era stata hackerata dagli attacchi russi trasformandola in un datacenter per attacchi?
è vero che ora Linode è Akamai ma potrebbe essere (solo ipotesi da bar) che alcuni server siano ancora usati per attacchi e per sicurezza abbiano chiuso gli ip da .xxx a .yyy anzichè indicare esattamente le numerazioni.
non sempre il service provider di consegna IP consecutivi. quindi potresti avere il .105,.106,.109,.111 mentre gli attacchi provenire da un server hackerato che ha gli ip …110,.112, .113, .114 e che sogei abbia bloccato da .110 a .114 prendendo anche l’ipotetico ip .110 che appartiene a te.
ovviamente è solo una ipotesi da bar, senza fondamenta.
Noi al momento abbiamo problemi con OVH.
Abbiamo due server, uno quello bloccato con ip 51.*, il secondario da cui al momento abbiamo dirottato gli endpoint di ricezione e la trasmissione delle fatture che non ha blocchi e ha ip 37.*
Vediamo se qualcuno richiamera’, al momento sono due giorni che aspettiamo un ricontatto…
L’unica soluzione è cambiare IP trasferendo il server o facendo le chiamate tramite proxy perché Sogei nega ogni tipo di responsabilità (a me hanno smesso proprio di rispondere)
Noi abbiamo messo su un server di backup per il servizio trasmissione e ricezione modificando poi gli endpoint.
Comunque dopo:
22 giorni
10+ call al supporto sempre con risposte vaghe
3 tentativi di chiusura ticket per “risolto”
ultime call la risposta standard: “sono in corso verifiche”
Da ieri ha ripreso a funzionare l’ip di produzione.
Al ricontatto da parte del supporto non han saputo dirmi se era o non era stato fatto qualcosa, ne per il blocco ne per la risoluzione.
Al momento sembra tutto funzionante.
Per la mia esperienza, se continui a rompere magari risolvono, ma non ti aspettare tempi brevi.
Se hai anche tu il problema la soluzione piu veloce e’ o con un server di backup o con un proxy.
Ok. Inserisco qua la mia soluzione, decisamente più semplice, trovata per il mio cliente con lo stesso problema.
Risolto tutto con un abbonamento NordVPN.
Installata la app NordVPN sul Computer/Server e a quel punto ogni browser o software sul Computer/Server viene visto dai sistemi Sogei con l’indirizzo IP del server VPN… quindi lascia passare…
RISOLTO con pochi euro l’anno e senza troppa fatica…
Chi ha bisogno di info mi chieda pure
Scusa la domanda, ma per la ricezione delle fatture e notifiche?
Quando noi abbiamo avuto il blocco era anche in fase di ricezione non solo trasmissione, a quel punto con una VPN di questo tipo non potrai ricevere flussi in ingresso…
Un everse proxy o in nuovo servizio avrebbe più senso
Nessun problema riscontrato per ora… ma siamo in fase di rodaggio… per ora riceviamo e inviamo tranquillamente… se ci sono problemi vi aggiorno.
Si capiscono quello che dici sul Reverse Proxy ma se mi funziona tutto così diciamo che la soluzione risulta decisamente più “semplice”.
Poi, naturalmente dipende dalle casistiche … in questo caso il computer che si occupa di ricezione e invio è uno solo quindi è semplice… in realtà la casistica vale anche per situazioni più complesse con maggior numero di computer, oppure con la vpn installata direttamente sul server se tutti attingono da lui, oppure con la vpn installata direttamente sul router… sono tante casistiche…
questa si presenta come una soluzione semplice per una situazione semplice.
Successa la stessa cosa dal 30 AGOSTO 2024. Al mattino spedisco una fattura niente. Combatto coi certificati perché non mi autorizzava l’accesso e ad un certo punto la fattura viene spedita. Ho pensato che fosse tutto ok, senonché il lunedì successivo stessa cosa al mattino ho dei problemi a spedire mentre a mezzogiorno tutto a posto. Il giorno seguente ho lo stesso problema ma stavolta in modo permanente.
Allora lancio il comando dal terminale: “openssl s_client -connect servizi.fatturapa.it:443” e la risposta è un bel timeout, mentre se lo lancio dal mio computer risponde perfettamente.
Decido di chiamare l’assistenza contattando il numero verde per una ventina di volte, mi richiamano loro dicendo di aver sbloccato il tutto ma in realtà non era successo niente e il problema permaneva.
Ho risolto così ho creato un clone del server con un altro indirizzo IP e cambiato i valori sui DNS del dominio. Dopo aver fatto il refresh delle cache DNS sui vari gestionali che interrogano l’api è ripartito il tutto ed ho cominciato di nuovo a spedire e a ricevere fatture senza problemi.