TCP fungerer og UDP når en annen server på samme port

En profil fungerer over TCP og feiler over UDP med en sertifikatadvarsel. Den intuitive lesningen er at UDP-veien brøt tilliten, og den intuitive rettelsen er å godta sertifikatet. Begge antakelsene hopper over en mulighet som forklarer symptomet fullstendig: de to transportene nådde forskjellige maskiner. En videresendingsregel matches per protokoll, og ingenting tvinger TCP- og UDP-halvdelen av ett portnummer til å peke på samme vert.

Ett portnummer, to uavhengige regler

Videresending er et tabelloppslag på protokoll, destinasjonsadresse og port. En gateway med en regel for TCP 1194 og en regel for UDP 1194 uttrykker to uavhengige beslutninger, og de kan navngi forskjellige interne verter. Det felles nummeret er en bekvemmelighet for mennesker, ikke en egenskap nettverket håndhever. Behandle portnummeret som en etikett og ikke som en tjenestedefinisjon.

Se på de effektive reglene i stedet for de tiltenkte. Destinasjonsadresse, oversatt port og inngående grensesnitt deltar alle, og en gjenglemt regel fra en tidligere migrering er den vanlige grunnen til at de to halvdelene ikke stemmer overens.

Skriv ned begge mappingene før du endrer noe annet. Linjeparet er hele hypotesen.

Hva klienten faktisk verifiserte

Under håndtrykket kontrollerer klienten sertifikatet mot sin konfigurerte tillit og mot navnet den forventer. Et uventet sertifikat er en vellykket verifisering som feilet identitetskontrollen, og det er det riktige utfallet når motparten ikke er den du ville nå. Å avvise det er bevis for at klienten virker, ikke for at transporten er ødelagt. Les det rapporterte navnet før den rapporterte kjeden, fordi navnet er det klienten sammenlignet.

Forskjellen betyr noe fordi de to feilene fører til forskjellige rettelser. Et tillitsproblem trenger en tillitsrettelse, mens en uventet motpart trenger en rettelse av ruting eller videresending.

Noter hvilken identitet klienten rapporterte. Det navnet er det sterkeste hintet om hvilken maskin som svarte.

Koble forsøket til en server

Noter profilen, den offentlige adressen, transporten og porten klienten brukte. Sammenhold deretter forsøkstidspunktet med loggen til serveren du ville nå. Fravær der er et spor og ikke bevis på at en brannmur droppet pakken, fordi loggnivåene varierer mellom installasjoner. Et tidsstempel sammen med en kildeadresse avgrenser mer enn hver av dem alene.

Sammenlign sertifikatidentiteten du møtte med den forventede identiteten via en administrativ kanal. Den sammenligningen utenfor kanalen er det som holder kontrollen troverdig.

Kontroller gamle videresendingsregler, alternative lyttere og enhver lastbalanseringsvei før du konkluderer med at begge transportene deler en backend. Hver av dem kan omdirigere en strøm uten å røre den andre transporten.

Ikke tilpass tilliten til en feil motpart

Import av den uventede CA-en får symptomet til å forsvinne og endrer hvem klienten stoler på. Det er en verre tilstand enn en mislykket tilkobling, fordi det skjuler avviket i stedet for å løse det. Det samme gjelder å slå av verifiseringen bare for å se om tunnelen kommer opp.

Hvis motparten viser seg å være legitim men utilsiktet, er riktig handling å avvikle den eller peke regelen mot riktig vert. Tillitslageret er ikke stedet for å avstemme en inventarfeil.

Ta vare på avvisningsteksten. Den er den eneste registreringen av hva klienten så.

Test en ny strøm etter rettelsen

Rett opp mappingen og koble deretter til med en ny klientsesjon. Tilstandsbasert oversettelse kan holde en eksisterende strøm pekt mot den gamle destinasjonen, slik at en etablert tilkobling kan overleve endringen og villede deg. Start en ny og bekreft i loggen til den tiltenkte serveren at den håndterte forsøket.

Hvis begge transportene bevislig når samme server og likevel oppfører seg forskjellig, er den gjenværende forskjellen den serverens egne lyttere og konfigurasjon. Transportsammenligningen betyr noe først når endepunktets identitet er fastlagt.