Am lucrat la o problemă de resetare a conexiunii cu traficul SVN după ce firewall-ul clientului meu a fost înlocuit cu un model Sophos XG la începutul anului trecut. Anterior a avut Sonicwall. Am deschis mai multe cazuri cu suport Sophos pentru a încerca să izolez problema și să o rezolv, dar fără rezultat.
Configurare curentă:
- Sediul din SUA este sediul central cu server SVN care rulează Fedora 15, Apache
2.2.22 și SVN 1.6.18.
- Există 3 filiale în alte 2 țări și există un VPN IPSec între sediul central și fiecare sucursală (topologie stea). NAT nu este în uz.
- Clienții SVN sunt pe Linux și Windows.
- Comunicarea pentru partajarea fișierelor Windows, site-ul web intern etc. nu au probleme
- Când încercați să rulați o comandă precum „svn up” pentru a actualiza sistemul local cu depozitul, captura de pachete va afișa traficul care trece între serverul SVN și client), dar după câteva secunde conexiunea va fi resetată
- Captura de pachete rulată pe ambele sisteme arată că un RST este trimis din cealaltă parte. Înseamnă că serverul va arăta că clientul trimite RST și clientul va arăta că serverul trimite RST.
- Regula de firewall pentru VPN este setată să permită tot traficul între sediul central și sucursale, fără filtrare.
- Un dezvoltator poate configura un tunel SSH între stația de lucru din sucursala și serverul SVN și poate sincroniza datele prin tunelul SSH, dar utilizarea comunicării directe între stația de lucru și server prin VPN provoacă resetarea conexiunii.
- Jurnalele de firewall nu arată că traficul este abandonat sau refuzat.
- Un reprezentant de asistență Sophos a crezut că problema poate fi legată de numărul MSS la examinarea captărilor de pachete, dar ajustarea acesteia pe ambele firewall-uri nu a făcut diferența.
Sunt pierdut în acest moment și caut să văd dacă cineva poate oferi indicii.
Editare: problema a fost identificată, Advanced Threat Protection din firewall a cauzat resetarea conexiunilor, chiar dacă am adăugat IP-urile serverului și clientului la lista de excepții. Chiar și setarea politicii de logare din „log and drop” nu a scuzat traficul de a fi blocat. A contactat furnizorul pentru a o revizui în continuare. Jurnalele nu arată blocarea/deconectarea traficului ATP.
