TCP funcționează, iar UDP ajunge la alt server pe același port

Un profil funcționează prin TCP și eșuează prin UDP cu un avertisment despre certificat. Citirea intuitivă este că traseul UDP a rupt încrederea, iar corectarea intuitivă este să acceptați certificatul. Ambele presupuneri omit o posibilitate care explică complet simptomul: cele două transporturi au ajuns la mașini diferite. O regulă de redirecționare se potrivește pe protocol, iar nimic nu obligă jumătățile TCP și UDP ale unui număr de port să indice același host.

Un număr de port, două reguli independente

Redirecționarea este o căutare în tabel după protocol, adresa de destinație și port. O poartă cu o regulă pentru TCP 1194 și o regulă pentru UDP 1194 exprimă două decizii independente, iar acestea pot numi hosturi interne diferite. Numărul comun este o comoditate pentru oameni, nu o proprietate pe care rețeaua o impune. Tratați numărul de port ca pe o etichetă, nu ca pe o definiție de serviciu.

Uitați-vă la regulile efective, nu la cele intenționate. Adresa de destinație, portul tradus și interfața de intrare participă toate, iar o regulă rămasă de la o migrare anterioară este motivul obișnuit pentru care cele două jumătăți nu concordă.

Notați ambele mapări înainte de a schimba orice altceva. Perechea de linii este întreaga ipoteză.

Ce a verificat de fapt clientul

În timpul handshake-ului clientul verifică certificatul față de încrederea configurată și față de numele pe care îl așteaptă. Un certificat neașteptat este o verificare reușită care a eșuat la controlul identității, iar acesta este rezultatul corect când partenerul nu este cel pe care voiați să îl atingeți. Respingerea lui este dovada că clientul funcționează, nu că transportul este stricat. Citiți numele raportat înaintea lanțului raportat, pentru că numele este ceea ce a comparat clientul.

Distincția contează pentru că cele două defecțiuni duc la corecturi diferite. O problemă de încredere are nevoie de o corectură a încrederii, în timp ce un partener neașteptat are nevoie de o corectură de rutare sau de redirecționare.

Notați ce identitate a raportat clientul. Acel nume este cel mai puternic indiciu despre ce mașină a răspuns.

Corelați încercarea cu un server

Înregistrați profilul, adresa publică, transportul și portul folosite de client. Apoi potriviți momentul încercării cu jurnalul serverului pe care voiați să îl atingeți. Absența de acolo este un indiciu, nu o dovadă a unei aruncări de către firewall, pentru că nivelurile de jurnalizare diferă între implementări. O marcă de timp împreună cu o adresă sursă restrânge mai mult decât oricare dintre ele singură.

Comparați identitatea certificatului întâlnit cu identitatea așteptată printr-un canal administrativ. Această comparație în afara canalului este cea care menține verificarea de încredere.

Verificați regulile vechi de redirecționare, ascultătorii alternativi și orice cale de echilibrare a încărcării înainte de a concluziona că ambele transporturi partajează un backend. Oricare dintre ele poate redirecționa un flux fără a atinge celălalt transport.

Nu adaptați încrederea la un partener greșit

Importarea CA-ului neașteptat face simptomul să dispară și schimbă în cine are încredere clientul. Aceasta este o stare mai rea decât o conexiune eșuată, pentru că ascunde nepotrivirea în loc să o rezolve. Același lucru este valabil pentru dezactivarea verificării doar ca să vedeți dacă tunelul se ridică.

Dacă partenerul se dovedește legitim, dar neintenționat, acțiunea corectă este să îl retrageți sau să îndreptați regula către hostul corect. Depozitul de încredere nu este locul unde se reconciliază o eroare de inventar.

Păstrați textul respingerii. Este singura înregistrare a ceea ce a văzut clientul.

După corectură, testați un flux nou

Corectați maparea și apoi conectați-vă cu o sesiune de client nouă. Traducerea cu stare poate ține un flux existent îndreptat spre destinația veche, așa că o conexiune stabilită poate supraviețui schimbării și vă poate induce în eroare. Porniți una nouă și confirmați în jurnalul serverului dorit că a tratat încercarea.

Dacă ambele transporturi ajung demonstrabil la același server și tot se comportă diferit, diferența rămasă sunt ascultătorii și configurația proprii acelui server. Comparația transporturilor are sens doar după ce identitatea punctului final este stabilită.