ESP er IP-protokol 50, ikke TCP-port 50: hvad der skal tillades

Firewall-formularer spørger om en TCP-port, og det oplagte svar er 50. Det svar tillader intet, fordi ESP er IP-protokol nummer 50, og protokolnumre er ikke porte. De to navnerum deler små heltal og intet andet, og fejlen er usynlig, indtil IKE er færdig, og den beskyttede trafik aldrig ankommer.

To navnerum, der deler små tal

Et IP-hovede bærer et protokolfelt, der navngiver det næste: 6 for TCP, 17 for UDP, 1 for ICMP, 50 for ESP, 51 for AH. Et TCP- eller UDP-hovede bærer portnumre, som vælger en proces på værtsmaskinen. Protokol 50 og TCP-port 50 er ubeslægtede værdier, som en dialogboks kan få til at se udskiftelige ud.

Derfor kan en videresendelsesregel for porte ikke udtrykke native ESP. Der er ingen ESP-destinationsport at videresende, og en enhed, der kun forstår portregler, har slet ikke noget ordforråd til den pakke. Den korrekte regel navngiver i stedet IP-protokollen. Enhver portdialog er det forkerte værktøj til den pakke.

Forvirringen har en anden halvdel. Når pakken er krypteret, er alt indeni uigennemsigtigt, inklusive TCP-hovedet i den oprindelige forbindelse. En firewall, der inspicerer porte i den pakke, kigger på det ydre hovede, som i det native tilfælde ikke har nogen porte at inspicere.

Native ESP, derefter det indkapslede alternativ

Native ESP bæres direkte som en IP-protokol, hvilket er lige så effektivt som besværligt. Det er effektivt, fordi der ikke er noget ekstra hovede, og besværligt, fordi enhver enhed, der oversætter adresser og porte, ikke kan følge det. NAT-traversal findes for at løse det ved at pakke ESP-pakken ind i UDP, så oversætteren har porte at omskrive.

De to former er alternative udrulninger af samme datakanal, ikke lag af én. At tillade native ESP tillader ikke den indkapslede form, og at tillade UDP 4500 tillader ikke native trafik, så et regelsæt skal matche udrulningen i stedet for at dække begge ved et tilfælde.

Registrering er også vigtig her. Endepunkterne vælger mellem formerne under forhandlingen, og skiftet sker normalt, når der registreres en NAT mellem dem. En rute, der ændrer sig, efter at tunnelen er etableret, kan derfor flytte trafikken til et navnerum, som dine regler aldrig dækkede.

Læs hvilken form forbindelsen faktisk bruger

Spørg endepunktet i stedet for at gætte ud fra firewalling. På Linux rapporterer tilstandsposten, om associationen bruger UDP-indkapsling, og hvilke porte der er involveret. En optagelse besvarer det samme spørgsmål fra ledningen, og begge er hurtigere end at læse et regelsæt og håbe.

ip xfrm state | grep -A3 encap
tcpdump -ni any 'ip proto 50 or udp port 4500'

Den første kommando viser en indkapslingstype, når NAT-traversal er i brug, og intet, når den ikke er. Den anden viser, hvilken af de to former der faktisk passerer grænsefladen, og det afslutter diskussioner om en opsætning, der ser rigtig ud på papiret.

Modbevis hører til i samme trin. En regel, der rapporterer nul træffere, fortæller dig, at pakken aldrig nåede den, og det er et routing- eller selektorspørgsmål, ikke et firewall-spørgsmål.

Bekræft derefter kontrolkanalen separat. IKE har sine egne porte og sine egne logfiler, og en afsluttet forhandling uden data er præcis den opdeling, denne artikel handler om.

Skriv reglen i det rigtige navnerum

En protokolregel og en portregel er forskellige instrukser, så værktøjet skal udtrykke den, du mener. I nftables er protokolmatchningen eksplicit, og det indkapslede alternativ får sin egen UDP-regel. Hold de to regler ved siden af hinanden, så parret er synligt ved gennemgang.

nft add rule inet filter input ip protocol esp accept
nft add rule inet filter input udp dport { 500, 4500 } accept

Lad være med at udvide nogen af reglerne for at kompensere for en fejldiagnose. En tillad-alt for ESP-protokollen på hver grænseflade eller en UDP-tilladelse fra hvad som helst til hvad som helst retter et symptom og fjerner den kontrol, du prøvede at opsætte. Den smalle understøttede strøm er næsten altid nok, når formen er kendt.

Endelig, hold lagene rigtige, når tunnelen virker, og applikationen ikke gør. Pakker, der ankommer til gatewayen, har stadig brug for videresendelse, en returrute og en politik, der tillader dem, og ingen af disse udtrykkes af en ESP-regel. Den manglende port forklarer en bestemt fejl, ikke enhver IPsec-fejl. Hold regelrettelsen og routingkontrollen som to separate konklusioner.

Notér den form, du observerede, den protokolregel, du tilføjede, og den tæller, du så bagefter. Tre linjer, og den næste person kan skelne en navnerumsfejl fra en routingfejl på et minut i stedet for en eftermiddag.