IKE su TCP 4500: verifica entrambi gli estremi prima della regola di porta
L'incapsulamento TCP viene negoziato da entrambi gli estremi, non concesso da una regola del firewall. Esegui il controllo del listener, la cattura e le quattro fasi di accettazione in ordine.
I ticket di supporto arrivano spesso con la modifica del firewall già approvata e il tunnel che ancora rifiuta di salire. È il risultato atteso quando solo un estremo ha la funzione: l'incapsulamento TCP secondo la RFC 9329 va implementato e configurato su entrambi gli estremi, e l'accordo avviene dentro la connessione prima che possa muoversi qualsiasi traffico protetto. Aprire una porta annuncia un listener che potrebbe non esistere, e un listener senza la configurazione corrispondente dall'altro lato accetta una connessione e poi tace. La sequenza seguente mette prima i controlli economici.
Sapere cosa aggiunge davvero l'opzione
L'IPsec nativo trasporta i payload cifrati come protocollo IP 50, senza un numero di porta da consentire. Il NAT traversal avvolge quei pacchetti in UDP verso la porta 4500, ed è per questo che tante regole del firewall citano quella porta. La RFC 9329 aggiunge una rappresentazione a flusso: i pacchetti IKE e IPsec viaggiano entrambi dentro un'unica connessione TCP, di solito verso la porta 4500.
Il flusso non è un servizio web. Una connessione TCP alla 4500 non dice nulla su HTTP, TLS o amichevolezza con un proxy, e un proxy HTTP sul percorso di solito spezzerà l'incorniciatura invece di trasportarla.
Verifica preliminare prima di toccare il firewall
Lo standard colloca TCP come ripiego per le reti che scartano il percorso UDP, non come suo sostituto. Ottieni due fatti da ogni fornitore: il nome esatto della funzione e la versione che implementa la RFC 9329 invece di una variante proprietaria. Etichette come IPsec over TCP sono state usate per progetti non correlati, quindi chiedi il riferimento al documento e la chiave di configurazione che la attiva. Senza entrambe le risposte, non dare nulla per scontato sulla compatibilità sul filo.
Dimostralo in un laboratorio dove entrambi gli estremi sono tuoi. Un gateway che risponde sulla TCP 4500 ma non completa mai IKE è la firma di un listener senza l'incapsulamento corrispondente dall'altro lato, e scoprirlo lì costa molto meno che durante una finestra di cambiamento.
Sul responder: c'è qualcosa in ascolto
Parti dal socket. ss -ltnp | grep 4500 mostra se esiste un listener TCP e quale processo lo possiede. L'assenza di una riga termina l'indagine sulla configurazione del gateway, non sulla rete.
Se il socket c'è, osserva l'handshake invece di indovinare dal lato client: tcpdump -ni any 'tcp port 4500'. Un handshake a tre vie completato seguito dal silenzio significa che il flusso è stato accettato e lo scambio IKE al suo interno è fallito, mentre un SYN senza risposta indica filtraggio o l'indirizzo sbagliato.
Confronta con il percorso UDP nella stessa finestra di cattura perché i due non si confondano: tcpdump -ni any 'udp port 4500 or proto 50'. Traffico sul protocollo 50 o sulla porta UDP 4500 mentre credi che si usi TCP significa che gli estremi non hanno mai concordato il ripiego. Cattura anche sul gateway se puoi, perché una cattura dal lato client non può mostrare cosa ha inviato l'estremo remoto.
Accetta in quattro fasi separate
Tratta la messa in servizio come quattro risultati. Ognuno può fallire per un motivo diverso, e un solo esito positivo o negativo nasconde quale sia stato, quindi fermati alla prima fase che fallisce e ricomincia dall'alto.
| 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 |
La quarta fase è quella che viene saltata. Una sessione esistente può continuare a funzionare su stato in cache, quindi apri una connessione nuova verso un host dietro il gateway prima di chiudere la modifica. Se la seconda fase fallisce mentre la prima passa, il disaccordo sta nella proposta o nell'impostazione di incapsulamento, non nel firewall.
Rollback e il costo di lasciarlo attivo
Pianifica l'annullamento prima della modifica: disattiva l'opzione di incapsulamento su entrambi gli estremi e conferma che il tunnel torni su UDP. Mantieni la regola TCP per un ciclo di revisione nel caso il ripiego serva di nuovo, poi rimuovila. Un listener inutilizzato sulla 4500 è superficie senza alcun valore operativo.
Osserva la firma delle prestazioni quando porterà lavoro reale. TCP dentro TCP aggiunge livelli di conferma che si bloccano su una singola perdita, e i flussi che condividono una connessione possono bloccarsi a vicenda, quindi misura l'applicazione che userà il tunnel invece di un ping.
Elenco di accettazione
Conferma il nome e la versione della funzione su entrambi gli estremi, il listener sul responder, la cattura che mostra un handshake completato e le quattro fasi registrate con marche temporali. Aggiungi il motivo del ripiego al registro delle modifiche così il prossimo ingegnere sa perché c'è TCP. Prova il rollback prima di averne bisogno.
Se una fase fallisce, correggi solo quella fase. Cambiare la suite di cifratura o le impostazioni di identità per inseguire un problema di trasporto di solito aggiunge un secondo guasto non correlato sopra il primo.