Długie nawiązywanie https

[kaschata 0]

Witam.

Od kilku dni walczę i walkę przegrywam. Niech mnie ktoś wesprze, bo żyły potnę wzdłuż, żeby nie odratowali. Do sedna.

Odziedziczyłem nieco skomplikowaną sieć a raczej kilka podsieci spiętych po IPSec przez pfSense (w czym nie jestem mocny).

Ograniczę się tylko do związanych z problemem.

 

Podsieć *.0.0: na *.0.1 jest zainstalowany Squid dla całej podsieci *.0.0, na *.0.9 jest DC01 (kontroler domeny), na 0.254 jest pfSense (a właściwie dwa połączone protokołem CARP, z wylotem na Świat i do innych podsieci)

 

Podsieć *.40.0: na *.40.10 jest DC03 (trzeci kontroler), na *.40.254 znów pfSense (bez CARP).

 

Problem: długie nawiązywanie połączeń https z podsieci *.40.0 (z dowolnej przeglądarki).

 

1. nslookup znajduje/widzi wszystkie kontrolery domeny, a jako "primary name server" podaje ze swojej podsieci (40.10).

 

2. tracert pokazuje trasę, gdzie trzeci hop jest * * * (! chyba ważne)

 

3. tcpdump na pfSense pokazuje, że po otrzymaniu odpowiedzi z DNS pakiety TCP-SYN z sieci *40.0 lecą dokładnie do Proxy *.0.1:8080, który jest dla niej niedostępny (celowo).

 

4. czyli tak jak tracert pokazuje: hop1 gateway, hop2 interfejs WAN, hop3 Proxy w IPSec (???), po time-out hop4 jakiś router dostawcy internetu...

 

Już nie mam pomysłów gdzie, jak i czym szukać powodu takiego przepływu pakietów. Owszem, sieci są połączone (IPSec) ale nigdzie w ustawieniach pfSense nie ma mowy o hoście *.0.1 nie mówiąc już o porcie 8080... Skąd to się bierze?

Pomoże ktoś, lub jakimś pomysłem rzuci, gdzie szukać?

Pozdrawiam

 

EDIT.:

Wygląda na to, że standardowa Windowsowa opcja "wykryj ustawienia proxy" działa, tylko nikt nie wie jak. 

W skrócie: po jej wyłączeniu pakiety do proxy przestały być wysyłane. Czyli windows sobie i tak owe proxy znalazł, choć dostępu do niego nie ma.

 

EDIT2:

A jednak nie. Mocno ograniczył ale nie zaprzestał... Uparte bydle.

Edytowane 19 Lutego 2020 przez kaschata

[SeN81 34]

A http działają normalnie ?

Próbowałeś uruchomić SQUIDa w sieci 40? Może pfSens z sieci 40 ma gdzieś zapisane aby szukać tego proxy w sieci 0 , a że nie ma do niego dostępu to czas odpowiedzi jest dość długi. Tak jak w przypadku pinga. Gdy host docelowy odpowiada to odpowiedź dostajesz szybko, jak host docelowy jest nieosiągalny to na komunikat braku hosta czeka się znaczeni dłużej.

[kaschata 0]

A gdzie teraz znajdziesz gołe http... Raczej nie.

SQUIDa w *40 nie próbowałem. pfSense to raczej nie jest. Przejrzałem już na wszystkie możliwe sposoby, wliczając przeszukanie wszystkich plików pod kątem *.0.1.

 

Znalazłem przypadkiem Wiresharkiem, że coś/system z 40.7 łączy się z http://wpad.moja.domena.com/wpad.dat (host *.0.6 - mimo wyłączonego "wykryj proxy automatycznie").

Rzut oka na zawartość wpad.dat, dopisałem parę linijek na początku:

 

    host = host.toLowerCase();
    var hostIP;[/size]
    var isIpV4Addr = /^(\d+.){3}\d+$/;
    if (isIpV4Addr.test (host))
      hostIP=host;
    else
      hostIP=dnsResolve (host);
    if (shExpMatch(hostIP, "192.168.40.*")) { return "DIRECT"; }[/size]

 

Na kompie 40.7 pozamykałem wszystkie (jedną) przeglądarki,

 

del \wpad*.dat /s
ipconfig /flushdns
nbtstat -R

 

Dla świętego spokoju restart.

I nic.

Zrobiłem jeszcze dla jaj na serwerze wpad...:

 iptables -I INPUT -s 192.168.40.7 -j REJECT

I jeszcze raz del \wpad itd...

Zdaje się, że się odwalił... Ale nie chwalę dnia przed zachodem słońca.

Edytowane 19 Lutego 2020 przez kaschata