IKEv2 gebruik UDP 500 en 4500: watter een dra die data?

Die eerste uitruiling en die pad wat data dra, is nie dieselfde vloei nie. Kontroleer albei poorte, en onthou dat native ESP 'n protokolnummer is, nie 'n poort nie.

Om UDP 500 in die firewall oop te maak, laat die tonnel onderhandel, en dan hou die verbinding op om verkeer deur te stuur. Die poortlys was onvolledig eerder as verkeerd. IKEv2 begin op een socket en gaan in baie werklike ontplooiings op 'n ander voort, terwyl die nutslading glad nie 'n poort mag wees nie. Om die fases in volgorde te lees, verduidelik watter reël ontbreek.

Twee poorte, twee take

IKEv2 begin met 'n sleuteluitruiling op UDP 500, waar die eweknieë verifieer en 'n sekuriteitsassosiasie vir die tonnel vestig. Die datapad wat volg, is 'n aparte saak: dit kan native ESP wees, wat 'n IP-protokolnummer eerder as 'n poort is, of UDP-ingeplakte verkeer op 4500. Om dit in 'n firewall-oorsig uitmekaar te hou, is die verskil tussen 'n tonnel wat onderhandel en 'n tonnel wat werk. Een socket dra beheer en die ander dra die nutslading.

Daarom lewer 'n reël wat net 500 toelaat die verwarrendste simptoom in die hele protokolfamilie: onderhandeling slaag en niks nuttigs volg nie. Die toestand wys 'n eweknie, die log wys 'n gevestigde IKE SA, en die toepassing hou steeds aan om te verstryk. Die ontbrekende toestemming hoort by 'n ander vloei as die een wat pas geslaag het.

Waarom 4500 hoegenaamd bestaan

Baie NAT-toestelle kan nie 'n ander protokol as TCP of UDP deurstuur nie, en sommige herskryf adresse op maniere wat ESP se integriteitskontrole breek. Om ESP in UDP in te kapsel, los albei probleme op, teen die koste van 'n ekstra kop en 'n tweede poort wat toegelaat moet word. Daardie inkapseling is die rede waarom die tweede poort hoegenaamd bestaan.

Sodra NAT bespeur word, skuif IKE self ook na 4500 sodat alle verkeer een pad deur die vertaler deel. 'n Merker van vier grepe wat nie ESP is nie, onderskei beheerboodskappe van data op daardie socket. Die skakel is 'n protokolbesluit eerder as 'n administrateur se voorkeur.

Waar die bronpoort verander

'n Vertaler kan die kliënt se bronpoort herskryf, so die tuple wat by die bediener gesien word, stem nie ooreen met die tuple op die kliënt nie. Kyk na albei kante van elke NAT-hop voordat jy tot die gevolgtrekking kom dat 'n reël geïgnoreer word. Foutsoeking net by die kliënt kan 'n reël lewer wat korrek lyk en steeds misluk.

MOBIKE-geskikte implementerings kan ook na 4500 skuif sonder dat NAT bespeur is, en sommige ontplooiings forseer daardie pad doelbewus. Om 4500 te sien is dus bewys van 'n besluit, nie 'n bewys van 'n tuisroeteerder nie.

Kontroleer albei vloeie by elke grens

Stap deur die drie grense: die kliëntnetwerk, enige tussenliggende firewall en die bediener. Elkeen benodig die vloeie wat die ontplooiing dokumenteer, nie die vloeie uit 'n pos oor 'n ander een nie.

sudo swanctl --list-sas
sudo tcpdump -ni any 'udp port 500 or udp port 4500'
sudo iptables -S | grep -E '500|4500|esp'
ip xfrm state

Die ESP-reël in 'n firewall-lys is 'n protokolpassing, dus dek 'n poortreël dit nooit nie. As die operateur 'n pasgemaakte poort gebruik, volg die gedokumenteerde konfigurasie aan albei kante, want 'n kliënt kan nie 'n luisteraar op die bediener skep deur 'n bekende nommer te kies nie.

Teken op waar onderhandeling gestop het en of 'n child-sekuriteitsassosiasie geïnstalleer is, want daardie paar skei 'n geblokkeerde pad van 'n verifikasie- of beleidsfout. Herhaal dan die toets met bedienerverifikasie geaktiveer, want bereikbaarheid is nie verifikasie nie. Daardie laaste stap skei 'n toegelate poort van 'n vertroude eweknie.

Verwante artikels