TCP werkt en UDP bereikt een andere server op dezelfde poort
Hetzelfde adres en hetzelfde poortnummer kunnen TCP en UDP naar verschillende machines doorsturen. Controleer de backend voordat u een onverwachte CA importeert of het vertrouwen aanpast.
Een profiel werkt via TCP en mislukt via UDP met een certificaatwaarschuwing. De intuïtieve lezing is dat het UDP-pad het vertrouwen heeft gebroken, en de intuïtieve oplossing is het certificaat accepteren. Beide aannames slaan een mogelijkheid over die het symptoom volledig verklaart: de twee transporten bereikten verschillende machines. Een doorstuurregele wordt per protocol gematcht, en niets dwingt de TCP- en UDP-helft van één poortnummer naar dezelfde host te wijzen.
Eén poortnummer, twee onafhankelijke regels
Doorsturen is een tabelopzoeking op protocol, bestemmingsadres en poort. Een gateway met een regel voor TCP 1194 en een regel voor UDP 1194 drukt twee onafhankelijke beslissingen uit, en die kunnen verschillende interne hosts noemen. Het gedeelde nummer is een gemak voor mensen, geen eigenschap die het netwerk afdwingt. Behandel het poortnummer als een label en niet als een dienstdefinitie.
Kijk naar de werkende regels in plaats van de bedoelde. Bestemmingsadres, vertaalde poort en inkomende interface doen allemaal mee, en een achtergebleven regel uit een eerdere migratie is de gebruikelijke reden dat de twee helften niet overeenkomen.
Schrijf beide mappings op voordat u iets anders wijzigt. Het paar regels is de hele hypothese.
Wat de client werkelijk heeft geverifieerd
Tijdens de handshake controleert de client het certificaat tegen het geconfigureerde vertrouwen en tegen de naam die hij verwacht. Een onverwacht certificaat is een geslaagde verificatie die de identiteitscontrole niet doorstond, en dat is de juiste uitkomst wanneer de tegenpartij niet degene is die u wilde bereiken. Het weigeren bewijst dat de client werkt, niet dat het transport stuk is. Lees de gemelde naam vóór de gemelde keten, want de naam is wat de client heeft vergeleken.
Het onderscheid is belangrijk omdat de twee fouten tot verschillende oplossingen leiden. Een vertrouwensprobleem vraagt om een vertrouwensoplossing, terwijl een onverwachte tegenpartij om een routerings- of doorstuuroplossing vraagt.
Noteer welke identiteit de client meldde. Die naam is de sterkste aanwijzing over welke machine antwoordde.
De poging aan een server koppelen
Leg het profiel, het openbare adres, het transport en de poort vast die de client gebruikte. Vergelijk daarna het tijdstip van de poging met het logboek van de server die u wilde bereiken. Ontbreken daar is een aanwijzing en geen bewijs van een firewall-drop, omdat logniveaus per implementatie verschillen. Een tijdstempel plus een bronadres beperkt het meer dan elk van beide alleen.
Vergelijk de certificaatidentiteit die u tegenkwam met de verwachte identiteit via een administratief kanaal. Die vergelijking buiten het kanaal is wat de controle betrouwbaar houdt.
Controleer oude doorstuuregels, alternatieve listeners en elk load-balancingpad voordat u concludeert dat beide transporten een backend delen. Elk daarvan kan een stroom omleiden zonder het andere transport te raken.
Pas het vertrouwen niet aan een verkeerde tegenpartij aan
Het importeren van de onverwachte CA laat het symptoom verdwijnen en verandert wie de client vertrouwt. Dat is een slechtere toestand dan een mislukte verbinding, omdat het de mismatch verbergt in plaats van oplost. Hetzelfde geldt voor het uitschakelen van de verificatie om alleen te zien of de tunnel omhoog komt.
Als de tegenpartij legitiem maar onbedoeld blijkt, is de juiste actie haar buiten gebruik stellen of de regel naar de juiste host richten. De vertrouwensopslag is niet de plek om een inventarisfout te verzoenen.
Bewaar de afwijzingstekst. Het is het enige verslag van wat de client zag.
Test na de oplossing een nieuwe stroom
Corrigeer de mapping en maak daarna verbinding met een nieuwe clientsessie. Stateful vertaling kan een bestaande stroom naar de oude bestemming laten wijzen, zodat een gevestigde verbinding de wijziging kan overleven en u kan misleiden. Start een nieuwe en bevestig in het logboek van de bedoelde server dat hij de poging heeft afgehandeld.
Als beide transporten aantoonbaar dezelfde server bereiken en zich toch anders gedragen, is het resterende verschil de eigen listeners en configuratie van die server. De transportvergelijking zegt pas iets als de identiteit van het eindpunt vaststaat.