Neregistrovaný Přihlásit Registrovat

Přidat otázku mezi oblíbenéZasílat nové odpovědi e-mailem 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)

Jsou zobrazeny jen nové odpovědi. Zobrazit všechny
Předmět Autor Datum
Pokud to dělá jen jeden server, viděl bych problém tam. Předpokládám tučňáka; jak máš nastavený sysc…
touchwood 21.06.2024 14:35
 touchwood
Ano vsetky su to nejake merace energie v strojoch od ZAPSI. Prikladam packet, ktory pride ako odpove…
fleg 21.06.2024 15:11
 fleg
Aha, takže nějaký embedded sráč? V tom případě bych rovnou vystřelil tiket na jejich podporu, protož…
touchwood 21.06.2024 22:42
 touchwood
Uz som s nimi volal, ale nic sme nevyriesili. Keby mali na <> ten server nemal by ist ani s lan, ci…
fleg 21.06.2024 22:44
 fleg
Já jsem bohužel potkal něco podobného (sice ne s ipsec) a bylo to firmwarem.
touchwood 22.06.2024 10:51
 touchwood
Tiez tusim nejaku takuto zradu. poslední
fleg 22.06.2024 11:16
 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).

Frame 6: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface \Device\NPF_{5D2ADFA8-8FAE-4046-891D-822F3298007B}, id 0
Ethernet II, Src: VMware_81:9a:b1 (00:50:56:81:9a:b1), Dst: VMware_81:cf:bd (00:50:56:81:cf:bd)
Destination: VMware_81:cf:bd (00:50:56:81:cf:bd)
Source: VMware_81:9a:b1 (00:50:56:81:9a:b1)
Type: IPv4 (0x0800)
Padding: 000000000000
Internet Protocol Version 4, Src: 192.168.3.90, Dst: 172.16.1.10
Transmission Control Protocol, Src Port: 80, Dst Port: 61396, Seq: 1, Ack: 1, Len: 0
Source Port: 80
Destination Port: 61396
[Stream index: 1]
[Conversation completeness: Incomplete (37)]
[TCP Segment Len: 0]
Sequence Number: 1 (relative sequence number)
Sequence Number (raw): 0
[Next Sequence Number: 1 (relative sequence number)]
Acknowledgment Number: 1 (relative ack number)
Acknowledgment number (raw): 2734093831
0101 .... = Header Length: 20 bytes (5)
Flags: 0x014 (RST, ACK)
000. .... .... = Reserved: Not set
...0 .... .... = Accurate ECN: Not set
.... 0... .... = Congestion Window Reduced: Not set
.... .0.. .... = ECN-Echo: Not set
.... ..0. .... = Urgent: Not set
.... ...1 .... = Acknowledgment: Set
.... .... 0... = Push: Not set
.... .... .1.. = Reset: Set
.... .... ..0. = Syn: Not set
.... .... ...0 = Fin: Not set
[TCP Flags: ·······A·R··]
Window: 0
[Calculated window size: 0]
[Window size scaling factor: -1 (unknown)]
Checksum: 0xb590 [unverified]
[Checksum Status: Unverified]
Urgent Pointer: 0
[Timestamps]
[SEQ/ACK analysis]

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.

Zpět do poradny Odpovědět na původní otázku Nahoru