IKE prin TCP 4500: verificați ambele capete înainte de regula de port
Încapsularea TCP este negociată de ambele capete, nu acordată de o regulă de firewall. Executați verificarea listenerului, captura și cele patru etape de acceptare în ordine.
Tichetele de suport ajung adesea cu modificarea firewallului deja aprobată și tunelul încă refuzând să urce. Acesta este rezultatul așteptat când doar un capăt are funcția: încapsularea TCP conform RFC 9329 trebuie implementată și configurată la ambele capete, iar acordul are loc în interiorul conexiunii înainte ca orice trafic protejat să se miște. Deschiderea unui port anunță un listener care poate să nu existe, iar un listener fără configurația corespunzătoare de cealaltă parte acceptă conexiunea și apoi tace. Secvența de mai jos pune verificările ieftine primele.
Știți ce adaugă de fapt opțiunea
IPsec nativ transportă încărcăturile criptate ca protocol IP 50, fără număr de port de permis. NAT traversal împachetează acele pachete în UDP către portul 4500, și de aceea atât de multe reguli de firewall menționează acel port. RFC 9329 adaugă o reprezentare de flux: pachetele IKE și IPsec călătoresc ambele într-o singură conexiune TCP, de obicei către portul 4500.
Fluxul nu este un serviciu web. O conexiune TCP la 4500 nu spune nimic despre HTTP, TLS sau prietenia cu un proxy, iar un proxy HTTP pe traseu va rupe de obicei încadrarea în loc să o transporte.
Verificare prealabilă înainte de a atinge firewallul
Standardul așază TCP ca alternativă pentru rețelele care aruncă traseul UDP, nu ca înlocuitor al acestuia. Obțineți două fapte de la fiecare furnizor: numele exact al funcției și versiunea care implementează RFC 9329 în locul unei variante proprietare. Etichete precum IPsec over TCP au fost folosite pentru proiecte neînrudite, așa că cereți referința documentului și cheia de configurare care o activează. Fără ambele răspunsuri, nu presupuneți nimic despre compatibilitatea pe cablu.
Demonstrați asta într-un laborator în care ambele capete sunt ale dumneavoastră. Un gateway care răspunde pe TCP 4500 dar nu finalizează niciodată IKE este semnătura unui listener fără încapsularea corespunzătoare de cealaltă parte, iar descoperirea acolo costă mult mai puțin decât în timpul unei ferestre de schimbare.
Pe partea care răspunde: ascultă ceva
Începeți cu socketul. ss -ltnp | grep 4500 arată dacă există un listener TCP și ce proces îl deține. Absența unei linii încheie investigația la configurația gatewayului, nu la rețea.
Dacă socketul există, urmăriți strângerea de mână în loc să ghiciți din partea clientului: tcpdump -ni any 'tcp port 4500'. O strângere de mână în trei pași finalizată, urmată de tăcere, înseamnă că fluxul a fost acceptat și schimbul IKE din interior a eșuat, în timp ce un SYN fără răspuns indică filtrare sau adresa greșită.
Comparați cu traseul UDP în aceeași fereastră de captură ca să nu se confunde: tcpdump -ni any 'udp port 4500 or proto 50'. Trafic pe protocolul 50 sau pe portul UDP 4500 când credeți că se folosește TCP înseamnă că părțile nu au convenit niciodată asupra alternativei. Capturați și pe gateway dacă puteți, pentru că o captură din partea clientului nu poate arăta ce a trimis capătul îndepărtat.
Acceptați în patru etape separate
Tratați ridicarea ca patru rezultate. Fiecare poate eșua dintr-un motiv diferit, iar un singur trecut sau eșuat ascunde care a fost, așa că opriți-vă la prima etapă care eșuează și începeți din nou de sus.
| Stage | What you check | What it proves |
|---|---|---|
| 1 | TCP connection established to 4500 | A listener exists and the path permits it |
| 2 | IKE_SA authenticated in the gateway log | Both peers agreed on the encapsulation |
| 3 | CHILD_SA installed, visible with ip xfrm state | Keys exist for the protected traffic |
| 4 | A new application exchange succeeds | The data path works, not just the control path |
A patra etapă este cea care se sare. O sesiune existentă poate continua să funcționeze pe stare din cache, așa că deschideți o conexiune nouă către un host din spatele gatewayului înainte de a închide schimbarea. Dacă a doua etapă eșuează în timp ce prima trece, neînțelegerea stă în propunere sau în setarea de încapsulare, nu în firewall.
Revenirea și costul de a lăsa asta pornit
Planificați anularea înainte de schimbare: opriți opțiunea de încapsulare la ambele capete și confirmați că tunelul revine prin UDP. Păstrați regula TCP pentru un ciclu de revizuire în caz că alternativa va fi din nou necesară, apoi eliminați-o. Un listener nefolosit pe 4500 este suprafață fără nicio valoare operațională.
Urmăriți semnătura de performanță când va transporta muncă reală. TCP în TCP adaugă straturi de confirmare care se blochează la o singură pierdere, iar fluxurile care împart o conexiune se pot bloca reciproc, așa că măsurați aplicația care va folosi tunelul în loc de un ping.
Listă de acceptare
Confirmați numele și versiunea funcției la ambele capete, listenerul pe partea care răspunde, captura care arată o strângere de mână finalizată și cele patru etape înregistrate cu momente de timp. Adăugați motivul alternativei la înregistrarea schimbării ca următorul inginer să știe de ce există TCP acolo. Exersați revenirea înainte de a avea nevoie de ea.
Dacă orice etapă eșuează, reparați doar acea etapă. Schimbarea suitei de cifrare sau a setărilor de identitate pentru a urmări o problemă de transport adaugă de obicei o a doua eșuare, nelegată, peste prima.