Vyssi divci, 1 http server nezobrazi obsah cez IPSEC
Zakaznik ma cloud v CR, s ktorym je spojeny cez IPSEC.
Na svojej LAN sieti ma nejake zariadenia s webovym serverom, ktore sa vsak nezobrazuju v prehliadacoch virtualov v cloude.
Zariadenie sa korektne zobrazi z LAN, ci z VPN, ale zo siete za IPSECom nie.
Pritom ine web servre na LAN sieti zakaznika komunikuju normalne, takze predbezne vylucujem problem v IPSEC.
Analyzou packetov som zistil, ze po poziadavke na GET HTTP/1.1 odpovie webovy server z LAN, ci z VPN dalsim PSH/ACK packetom, ale do IPSEC posle RST, ACK, cim zrusi spojenie.
Otazka znie preco, povodne som hladal problem v MSS, ale to je rovnake na zaciatku komunikacie ako s inymi web servermi na LAN, s ktorymi IPSEC normalne komunikuje (Mikrotik, Apache, IIS), takze tu by som problem nehladal.
Vie ma niekto nejako nakopnut?
Riesil niekto nieco taketo?
Zmena predmetu, pôvodne: Vyssi divci, 1 http server neodpoveda cez IPSEC (fleg)
Pokud to dělá jen jeden server, viděl bych problém tam. Předpokládám tučňáka; jak máš nastavený sysctl.conf, zejména věci jako reverse path filter? Je to taková střelba do tmy, ale čekal bych nějakou takovou zradu...
edit: přečetl jsem znova a asi jsem to špatně pochopil: ty těch zařízení máš vícero a nechodí všechna?
Ano vsetky su to nejake merace energie v strojoch od ZAPSI.
Prikladam packet, ktory pride ako odpoved na poziadavke GET HTTP 1.1 od klienta (prehliadacu).
Za normalnych okolnosti pride HTTP packet so zobrazenim stranky, tu vsak dojde evidentne k resetu spojenia.
K meracom su aj nejake terminaly s vlastnou IP a web serverom a tie odpovedaju normalne.
Aha, takže nějaký embedded sráč? V tom případě bych rovnou vystřelil tiket na jejich podporu, protože téměř jistě tam budou mít nějakou chybu.
Uz som s nimi volal, ale nic sme nevyriesili. Keby mali na <> ten server nemal by ist ani s lan, ci VPN, takze to ma trosku matie.
Ich technik to bude konzultovat s dalsim, po telefone som mal pocit, ze nebol uplne blby, ale nikam ma neposunul.
Já jsem bohužel potkal něco podobného (sice ne s ipsec) a bylo to firmwarem.
Tiez tusim nejaku takuto zradu.
jsou IP adresy správné, jak mají být, dochází tam někde k překladu? Naslouchá server na správné adrese
Nedochází tam k nějakému podivnému směrování paketů ?Chodí pakety stále stejnou cestou? Z jakých rosahů jsou adresy? Je tam něco jako conntrack?
Můžeš zkusit z linuxového stroje tool o úroveň nižší než wget/curl, a to nc (netcat)
Není tam někde na tunelu povolený jiný rosahu adres které může akcpetovat? (Jako wireguard allowed-ips))?
Není tam konflikt IP adres či rozsahů?, Není tam někde v cestě firewall? Nevím, jak funguje FW ve vidlích, ale něco na způsob, co zakazuje příchozí odchozí spojení.
To RST se mi zdá, jako kdyby pakety chodil někam kam nemají (špatné routování)
Dělá to víc serverů(i s linuxem)?
Wndows a IPSEC, to je taková černá magie.
Trosku kecas, pisal som, ze cez IPSEC funguju akykolvek iny web server, len tieto merace nie. Chyba bude u nich len mi nejde do hlavy aka, pretoze cez VPN, ci LAN idu aj tie.
Není možné, že ten měřič má v sobě ještě nějaký access list?
Teoreticky ano, skor nie, pretoze hoci ma ipecku /23 pusta aj ip z rozsahu /19.
On ma ip z rozsahu 192.168.2.0/23, IPSEC preroutovava celu 192.168.0.0/19, pretoze 192.168,30.0/24 su vpn klienti.
IPSEC siet na druhej strane je 172.16.1.0/24.
Je tam niekolko vlanov, ale vsetko mimo podozrenia, 6,8,11,12,13,22 (192.168.6.0/24...atd).
Nechápeš. Není na těch měřičích ještě něco jako firewall, seznam povolených adres?
Ale chapem, skor ty nechapes mna... pisal som, ze netusim, ci je, ale nemyslim si, ze je, pretoze merac ma adres /23, ale pusta v pohode aj z rozsahu /19, o ktorom nemoze merac tusit, kedze si mysli, ze je na sieti /23.
Navyse som tu uz dolozil, ze kludne zacne komunikovat aj s inym rozsahom ako 192.168, pretoze test spojenia na 80 port je uspesny (rovnako telnet test na 80 port).
Odpoveda aj na icmp packety.