En profil virker over TCP og fejler over UDP med en certifikatadvarsel. Den intuitive læsning er, at UDP-stien brød tilliden, og den intuitive rettelse er at acceptere certifikatet. Begge antagelser springer en mulighed over, som forklarer symptomet fuldt ud: de to transportlag nåede forskellige maskiner. En videresendelsesregel matches per protokol, og intet tvinger TCP- og UDP-halvdelen af ét portnummer til at pege på samme vært.

Ét portnummer, to uafhængige regler

Videresendelse er en tabelopslag baseret på protokol, destinationsadresse og port. En gateway med en regel for TCP 1194 og en regel for UDP 1194 udtrykker to uafhængige beslutninger, og de kan navngive forskellige interne værter. Det fælles nummer er en bekvemmelighed for mennesker, ikke en egenskab, som netværket håndhæver. Behandl portnummeret som en etiket og ikke som en tjenestedefinition.

Se på de effektive regler i stedet for de tilsigtede. Destinationsadresse, oversat port og indgående interface deltager alle, og en efterladt regel fra en tidligere migrering er den sædvanlige grund til, at de to halvdele ikke stemmer overens.

Skriv begge mappinger ned, før du ændrer noget andet. Linjeparret er hele hypotesen.

Hvad klienten faktisk verificerede

Under handshaket kontrollerer klienten certifikatet mod sin konfigurerede tillid og mod det navn, den forventer. Et uventet certifikat er en vellykket verifikation, som fejlede identitetskontrollen, og det er det korrekte udfald, når modparten ikke er den, du ville nå. At afvise det er bevis for, at klienten virker, ikke for at transportlaget er i stykker. Læs det rapporterede navn før den rapporterede kæde, for navnet er det, klienten sammenlignede.

Forskellen betyder noget, fordi de to fejl fører til forskellige rettelser. Et tillidsproblem kræver en tillidsrettelse, mens en uventet modpart kræver en rettelse af routing eller videresendelse.

Noter, hvilken identitet klienten rapporterede. Det navn er det stærkeste fingerpeg om, hvilken maskine der svarede.

Kobl forsøget til en server

Noter profilen, den offentlige adresse, transportlaget og den port, klienten brugte. Sammenhold derefter forsøgets tidspunkt med loggen fra den server, du ville nå. Fravær der er et spor og ikke bevis for, at en firewall har droppet pakken, fordi logningsniveauer varierer mellem installationer. Et tidsstempel sammen med en kildeaddresse indsnævrer det mere end hver af dem alene.

Sammenlign den certifikatidentitet, du stødte på, med den forventede identitet via en administrativ kanal. Den sammenligning uden for kanalen er det, der holder kontrollen troværdig.

Kontroller gamle videresendelsesregler, alternative lyttere og enhver lastbalanceringssti, før du konkluderer, at begge transportlag deler en backend. Hver af dem kan omdirigere en strøm uden at røre det andet transportlag.

Tilpas ikke tilliden til en forkert modpart

Import af den uventede CA får symptomet til at forsvinde og ændrer, hvem klienten har tillid til. Det er en værre tilstand end en mislykket forbindelse, fordi den skjuler uoverensstemmelsen i stedet for at løse den. Det samme gælder deaktivering af verifikationen blot for at se, om tunnelen kommer op.

Hvis modparten viser sig legitim men utilsigtet, er den rigtige handling at tage den ud af drift eller pege reglen mod den rigtige vært. Tillidslageret er ikke stedet at afstemme en fejl i fortegnelsen.

Gem afvisningsteksten. Den er den eneste registrering af, hvad klienten så.

Test en ny strøm efter rettelsen

Ret mappingen, og opret derefter forbindelse med en ny klientsession. Stateful oversættelse kan holde en eksisterende strøm peget på den gamle destination, så en etableret forbindelse kan overleve ændringen og vildlede dig. Start en ny, og bekræft i den tilsigtede servers log, at den håndterede forsøget.

Hvis begge transportlag påviseligt når samme server og stadig opfører sig forskelligt, er den resterende forskel den pågældende servers egne lyttere og konfiguration. Sammenligningen af transportlag betyder kun noget, når endepunktets identitet er fastlagt.

Relaterede artikler