ESP is IP-protokol 50, nie TCP-poort 50 nie: wat om toe te laat
Protokolnommers en poortnommers is verskillende naamruimtes. ’n Reël vir TCP-poort 50 laat niks deur nie, en NAT-traversal skuif ESP na UDP 4500.
Firewall-vorms vra vir ’n TCP-poort, en die ooglopende inskrywing is 50. Daardie inskrywing laat niks deur nie, want ESP is IP-protokolnommer 50 en protokolnommers is nie poorte nie. Die twee naamruimtes deel klein heelgetalle en niks anders nie, en die fout bly onsigbaar totdat IKE klaarmaak en die beskermde verkeer nooit aankom nie.
Twee naamruimtes wat klein getalle deel
’n IP-opskrif dra ’n protokolveld wat benoem wat volgende kom: 6 vir TCP, 17 vir UDP, 1 vir ICMP, 50 vir ESP, 51 vir AH. ’n TCP- of UDP-opskrif dra poortnommers, wat ’n proses op die bestemming-gasheer kies. Protokol 50 en TCP-poort 50 is onverwante waardes, maar ’n dialoog kan hulle so laat lyk of hulle uitruilbaar is.
Dis hoekom ’n poortaanstuur-reël nie inheemse ESP kan uitdruk nie. Daar is geen ESP-bestemmingspoort om aan te stuur nie, en ’n toestel wat net poortreëls verstaan, het glad nie ’n woordeskat vir die pakket nie. Die korrekte reël benoem eerder die IP-protokol. Enige poortdialoog is die verkeerde instrument vir daardie pakket.
Die verwarring het ’n tweede helfte. Wanneer die pakket geïnkripteer is, is alles binne-in ondeursigtig, insluitend die TCP-opskrif van die oorspronklike verbinding. ’n Firewall wat poorte op daardie pakket ondersoek, kyk na die buitenste opskrif, wat in die inheemse geval geen poorte het om te ondersoek nie.
Inheemse ESP, dan die ingekapselde alternatief
Inheemse ESP word direk as ’n IP-protokol gedra, wat ewe doeltreffend as ongemaklik is. Dit is doeltreffend omdat daar geen ekstra opskrif is nie, en ongemaklik omdat enige toestel wat adres- en poortomsetting doen dit nie kan volg nie. NAT-traversal bestaan om dit op te los, deur die ESP-pakket in UDP toe te draai sodat die omsetter poorte het om te herskryf.
| Form on the wire | How it is identified | What the firewall must permit |
|---|---|---|
| IKE negotiation | UDP with a destination port | UDP 500, and 4500 once traversal is detected |
| Native ESP | IP protocol 50 in the outer header | The protocol itself, with no port to name |
| ESP inside UDP | UDP 4500 carrying an ESP payload | The UDP port pair, which translation devices can track |
Die twee vorms is alternatiewe ontplooiings van dieselfde datakanaal, nie lae van een nie. Om inheemse ESP toe te laat, laat nie die ingekapselde vorm deur nie, en om UDP 4500 toe te laat, laat nie inheemse verkeer deur nie, so ’n reëlstel moet by die ontplooiing pas eerder as om beide per ongeluk te dek.
Opsporing maak hier ook saak. Die eindpunte kies tussen die vorms tydens onderhandeling, en die oorskakeling gebeur gewoonlik wanneer ’n NAT tussen hulle opgespoor word. ’n Pad wat verander nadat die tonnel gevestig is, kan dus die verkeer skuif na ’n naamruimte wat jou reëls nooit gedek het nie.
Lees watter vorm die verbinding werklik gebruik
Vra die eindpunt eerder as om uit die firewall te raai. Op Linux rapporteer die staat-inskrywing of die assosiasie UDP-inkapseling gebruik en watter poorte betrokke is. ’n Opname beantwoord dieselfde vraag van die draad af, en beide is vinniger as om ’n reëlstel te lees en te hoop.
ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'Die eerste opdrag wys ’n inkapselingstipe wanneer NAT-traversal in gebruik is en niks wanneer dit nie is nie. Die tweede wys watter van die twee vorms werklik die koppelvlak oorsteek, wat argumente besleg oor ’n opset wat op papier korrek lyk.
Teenbewys hoort in dieselfde stap. ’n Reël wat nul treffers rapporteer, sê vir jou die pakket het dit nooit bereik nie, en dit is ’n roete- of keurder-vraag eerder as ’n firewall-vraag.
Bevestig dan die beheerkanaal afsonderlik. IKE het sy eie poorte en sy eie logboeke, en ’n voltooide onderhandeling sonder data is presies die skeiding waaroor hierdie artikel gaan.
Skryf die reël in die regte naamruimte
’n Protokolreël en ’n poortreël is verskillende opdragte, so die gereedskap moet die een uitdruk wat jy bedoel. In nftables is die protokolpassing eksplisiet, en die ingekapselde alternatief kry sy eie UDP-reël. Hou die twee reëls langs mekaar sodat die paar in hersiening sigbaar is.
nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } acceptWeerstaan die drang om enige van die reëls te verbreed om ’n verkeerde diagnose te vergoed. ’n Laat-alles vir die ESP-protokol op elke koppelvlak, of ’n enige-tot-enige UDP-toelating, maak ’n simptoom reg en verwyder die beheer wat jy probeer opstel het. Die smal ondersteunde vloei is byna altyd genoeg sodra die vorm bekend is.
Laastens, hou die lae reguit wanneer die tonnel werk en die toepassing nie. Pakkette wat by die poort aankom, het steeds aanstuur, ’n terugroete en ’n beleid nodig wat hulle toelaat, en niks daarvan word deur ’n ESP-reël uitgedruk nie. Die ontbrekende poort verduidelik ’n spesifieke fout, nie elke IPsec-fout nie. Hou die reëlregstelling en die roetekontrole as twee afsonderlike gevolgtrekkings.
Teken die vorm aan wat jy waargeneem het, die protokolreël wat jy bygevoeg het en die teller wat jy daarna gesien het. Drie reëls, en die volgende persoon kan ’n naamruimtefout in ’n minuut van ’n roetefout onderskei, eerder as ’n middag.