TCP fungerar och UDP når en annan server på samma port

En profil fungerar över TCP och misslyckas över UDP med en certifikatvarning. Den intuitiva läsningen är att UDP-vägen bröt förtroendet, och den intuitiva åtgärden är att acceptera certifikatet. Båda antagandena hoppar över en möjlighet som förklarar symtomet helt: de två transporterna nådde olika maskiner. En vidarebefordringsregel matchas per protokoll, och inget tvingar TCP- och UDP-halvan av ett portnummer att peka på samma värd.

Ett portnummer, två oberoende regler

Vidarebefordran är en tabellsökning på protokoll, destinationsadress och port. En gateway med en regel för TCP 1194 och en regel för UDP 1194 uttrycker två oberoende beslut, och de kan namnge olika interna värdar. Det delade numret är en bekvämlighet för människor, inte en egenskap som nätverket upprätthåller. Behandla portnumret som en etikett och inte som en tjänstedefinition.

Titta på de gällande reglerna i stället för de avsedda. Destinationsadress, översatt port och ingående gränssnitt deltar alla, och en kvarglömd regel från en tidigare migrering är det vanliga skälet till att de två halvorna inte stämmer överens.

Skriv ned båda mappningarna innan du ändrar något annat. Radparet är hela hypotesen.

Vad klienten faktiskt verifierade

Under handskakningen kontrollerar klienten certifikatet mot sitt konfigurerade förtroende och mot det namn den förväntar sig. Ett oväntat certifikat är en lyckad verifiering som misslyckades med identitetskontrollen, vilket är rätt utfall när motparten inte är den du ville nå. Att avvisa det är bevis på att klienten fungerar, inte på att transporten är trasig. Läs det rapporterade namnet före den rapporterade kedjan, eftersom namnet är det klienten jämförde.

Skillnaden spelar roll eftersom de två felen leder till olika åtgärder. Ett förtroendeproblem kräver en förtroendeåtgärd, medan en oväntad motpart kräver en åtgärd för routing eller vidarebefordran.

Notera vilken identitet klienten rapporterade. Det namnet är den starkaste ledtråden till vilken maskin som svarade.

Koppla försöket till en server

Anteckna profilen, den offentliga adressen, transporten och porten som klienten använde. Matcha sedan försökets tid mot loggen från den server du ville nå. Att det saknas där är en ledtråd och inte bevis på att en brandvägg släppte paketet, eftersom loggnivåerna skiljer sig mellan installationer. En tidsstämpel tillsammans med en källadress avgränsar mer än var och en för sig.

Jämför den certifikatidentitet du stötte på med den förväntade identiteten via en administrativ kanal. Den jämförelsen utanför kanalen är det som håller kontrollen trovärdig.

Kontrollera gamla vidarebefordringsregler, alternativa lyssnare och varje lastbalanseringsväg innan du drar slutsatsen att båda transporterna delar en backend. Var och en av dem kan styra om ett flöde utan att röra den andra transporten.

Anpassa inte förtroendet till en felaktig motpart

Att importera den oväntade CA:n får symtomet att försvinna och ändrar vem klienten litar på. Det är ett sämre tillstånd än en misslyckad anslutning, eftersom det döljer avvikelsen i stället för att lösa den. Detsamma gäller att stänga av verifieringen bara för att se om tunneln kommer upp.

Om motparten visar sig legitim men oavsiktlig är rätt åtgärd att avveckla den eller peka regeln mot rätt värd. Förtroendelagret är inte platsen för att stämma av ett inventeringsfel.

Spara avvisningstexten. Den är den enda dokumentationen av vad klienten såg.

Testa ett nytt flöde efter åtgärden

Rätta mappningen och anslut sedan med en ny klientsession. Tillståndskänslig översättning kan hålla ett befintligt flöde riktat mot den gamla destinationen, så en etablerad anslutning kan överleva ändringen och vilseleda dig. Starta en ny och bekräfta i den avsedda serverns logg att den hanterade försöket.

Om båda transporterna bevisligen når samma server och ändå beter sig olika, är den återstående skillnaden den serverns egna lyssnare och konfiguration. Transportjämförelsen betyder något först när slutpunktens identitet är fastställd.