TCP funguje a UDP se na stejném portu dostane na jiný server

Profil funguje přes TCP a selhává přes UDP s varováním o certifikátu. Intuitivní čtení je, že cesta UDP narušila důvěru, a intuitivní oprava je certifikát přijmout. Oba předpoklady přeskakují možnost, která příznak zcela vysvětluje: oba přenosy dorazily na různé stroje. Pravidlo přeposílání se páruje podle protokolu a nic nenutí poloviny TCP a UDP jednoho čísla portu ukazovat na stejný hostitel.

Jedno číslo portu, dvě nezávislá pravidla

Přeposílání je vyhledání v tabulce podle protokolu, cílové adresy a portu. Brána s pravidlem pro TCP 1194 a pravidlem pro UDP 1194 vyjadřuje dvě nezávislá rozhodnutí a ta mohou jmenovat různé interní hostitele. Sdílené číslo je pohodlí pro lidi, ne vlastnost, kterou by síť vynucovala. Berte číslo portu jako označení, ne jako definici služby.

Dívejte se na platná pravidla, ne na zamýšlená. Cílová adresa, přeložený port a vstupní rozhraní se všechny účastní, a pravidlo zbylé z dřívější migrace je obvyklým důvodem, proč se obě poloviny neshodují.

Zapište obě mapování, než změníte cokoli jiného. Dvojice řádků je celá hypotéza.

Co klient skutečně ověřil

Během handshake klient kontroluje certifikát proti nastavené důvěře a proti očekávanému názvu. Neočekávaný certifikát je úspěšné ověření, které neprošlo kontrolou totožnosti, a to je správný výsledek, když protistrana není ta, kterou jste chtěli dosáhnout. Jeho odmítnutí je důkaz, že klient funguje, ne že je přenos rozbitý. Čtěte nahlášený název před nahlášeným řetězem, protože název je to, co klient porovnal.

Rozdíl je důležitý, protože obě chyby vedou k různým opravám. Problém důvěry potřebuje opravu důvěry, zatímco neočekávaná protistrana potřebuje opravu směrování nebo přeposílání.

Poznamenejte, jakou totožnost klient nahlásil. Ten název je nejsilnější stopa, který stroj odpověděl.

Spojte pokus se serverem

Zaznamenejte profil, veřejnou adresu, přenos a port, které klient použil. Potom porovnejte čas pokusu s logem serveru, kterého jste chtěli dosáhnout. Jeho nepřítomnost je stopa, ne důkaz, že firewall paket zahodil, protože úrovně protokolování se mezi nasazeními liší. Časové razítko spolu se zdrojovou adresou to zúží více než kterékoli z nich samo.

Porovnejte totožnost certifikátu, na kterou jste narazili, s očekávanou totožností prostřednictvím administrativního kanálu. Právě toto srovnání mimo kanál udržuje kontrolu důvěryhodnou.

Zkontrolujte stará pravidla přeposílání, alternativní posluchače a každou cestu vyrovnávání zátěže, než usoudíte, že oba přenosy sdílejí backend. Každá z nich může přesměrovat tok, aniž by se dotkla druhého přenosu.

Nepřizpůsobujte důvěru špatné protistraně

Import neočekávané CA nechá příznak zmizet a změní, komu klient důvěřuje. To je horší stav než neúspěšné připojení, protože skrývá nesoulad místo toho, aby ho řešil. Totéž platí pro vypnutí ověřování jen proto, abychom viděli, zda tunel vstane.

Pokud se protistrana ukáže jako legitimní, ale nezamýšlená, správným krokem je vyřadit ji nebo nasměrovat pravidlo na správného hostitele. Úložiště důvěry není místem pro srovnání chyby v inventáři.

Uchovejte text odmítnutí. Je to jediný záznam o tom, co klient viděl.

Po opravě otestujte nový tok

Opravte mapování a potom se připojte novou relací klienta. Stavový překlad může udržet existující tok na starém cíli, takže navázané spojení může změnu přežít a zmást vás. Spusťte nové a potvrďte v logu zamýšleného serveru, že pokus obsloužil.

Pokud oba přenosy prokazatelně dosáhnou stejného serveru a přesto se chovají různě, zbývajícím rozdílem jsou vlastní posluchače a konfigurace tohoto serveru. Srovnání přenosů má smysl teprve tehdy, když je totožnost koncového bodu pevně daná.