TCP fungerer og UDP når ein annan server på same port

Ein profil fungerer over TCP og feilar over UDP med ei sertifikatåtvaring. Den intuitive lesinga er at UDP-vegen braut tilliten, og den intuitive rettinga er å godta sertifikatet. Begge føresetnadene hoppar over ein moglegheit som forklarer symptomet fullt ut: dei to transportane nådde ulike maskinar. Ein vidaresendingsregel vert matcha per protokoll, og ingenting tvingar TCP- og UDP-halvdelen av eitt portnummer til å peike på same vert.

Eitt portnummer, to uavhengige reglar

Vidaresending er eit tabelloppslag på protokoll, måladdresse og port. Ein gateway med ein regel for TCP 1194 og ein regel for UDP 1194 uttrykkjer to uavhengige avgjerder, og dei kan namngje ulike interne vertar. Det felles nummeret er ein komfort for menneske, ikkje ein eigenskap nettverket handhevar. Handsame portnummeret som ein etikett og ikkje som ein tenestedefinisjon.

Sjå på dei effektive reglane i staden for dei tiltenkte. Måladdresse, omsett port og inngåande grensesnitt deltek alle, og ein attgløymd regel frå ein tidlegare migrasjon er den vanlege grunnen til at dei to halvdelane ikkje stemmer overeins.

Skriv ned båe mappingane før du endrar noko anna. Linjeparet er heile hypotesen.

Kva klienten faktisk verifiserte

Under handtrykket kontrollerer klienten sertifikatet mot sin konfigurerte tillit og mot namnet han forventar. Eit uventa sertifikat er ein vellukka verifisering som feila identitetskontrollen, og det er det rette utfallet når motparten ikkje er den du ville nå. Å avvise det er prov på at klienten verkar, ikkje på at transporten er øydelagd. Les det rapporterte namnet før den rapporterte kjeda, fordi namnet er det klienten samanlikna.

Skilnaden spelar rolle fordi dei to feila fører til ulike rettingar. Eit tillitsproblem treng ei tillitsretting, medan ein uventa motpart treng ei retting av ruting eller vidaresending.

Noter kva identitet klienten rapporterte. Det namnet er det sterkaste hintet om kva maskin som svara.

Kople forsøket til ein server

Noter profilen, den offentlege adressa, transporten og porten klienten brukte. Sammenhald deretter forsøkstidspunktet med loggen til serveren du ville nå. Fråvær der er eit spor og ikkje prov på at ein brannmur droppa pakken, fordi loggnivåa varierer mellom installasjonar. Eit tidsstempel saman med ei kjeldeaddresse avgrensar meir enn kvar av dei åleine.

Samanlikn sertifikatidentiteten du møtte med den forventa identiteten via ein administrativ kanal. Den samanlikninga utanfor kanalen er det som held kontrollen truverdig.

Kontroller gamle vidaresendingsreglar, alternative lyttarar og kvar lastbalanseringsveg før du konkluderer med at båe transportane deler ein backend. Kvar av dei kan omdirigere ein straum utan å røre den andre transporten.

Ikkje tilpass tilliten til ein feil motpart

Import av den uventa CA-en får symptomet til å forsvinne og endrar kven klienten stolar på. Det er ein verre tilstand enn ei mislukka tilkopling, fordi det skjuler avviket i staden for å løyse det. Det same gjeld å slå av verifiseringa berre for å sjå om tunnelen kjem opp.

Viser motparten seg å vere legitim men utilsikta, er rett handling å avvikle han eller peike regelen mot rett vert. Tillitslageret er ikkje staden for å avstemme ein inventarfeil.

Ta vare på avvisingsteksten. Han er den einaste registreringa av kva klienten såg.

Test ein ny straum etter rettinga

Rett opp mappinga og kople deretter til med ein ny klientsesjon. Tilstandsbasert omsetjing kan halde ein eksisterande straum peikt mot den gamle destinasjonen, slik at ei etablert tilkopling kan overleve endringa og villede deg. Start ein ny og stadfest i loggen til den tiltenkte serveren at han handsama forsøket.

Viss båe transportane bevisleg når same server og likevel oppfører seg ulikt, er den gjenverande skilnaden den serveren sine eigne lyttarar og konfigurasjon. Transportsamanlikninga betyr noko først når identiteten til endepunktet er fastlagd.