ESP är IP-protokoll 50, inte TCP-port 50: vad du måste tillåta

Brandväggsformulär frågar efter en TCP-port, och det självklara svaret är 50. Det svaret tillåter ingenting, eftersom ESP är IP-protokoll nummer 50 och protokollnummer är inte portar. De två namnrymderna delar små heltal och ingenting annat, och felet är osynligt tills IKE är klart och den skyddade trafiken aldrig kommer fram.

Två namnrymder som delar små tal

Ett IP-huvud bär ett protokollfält som namnger vad som kommer härnäst: 6 för TCP, 17 för UDP, 1 för ICMP, 50 för ESP, 51 för AH. Ett TCP- eller UDP-huvud bär portnummer, som väljer en process på målvärden. Protokoll 50 och TCP-port 50 är orelaterade värden, men en dialogruta kan få dem att se utbytbara ut.

Det är därför en vidarebefordringsregel för portar inte kan uttrycka inbyggd ESP. Det finns ingen ESP-målport att vidarebefordra, och en enhet som bara förstår portregler har inget ordförråd alls för det paketet. Den korrekta regeln namnger IP-protokollet i stället. Varje portdialog är fel verktyg för det paketet.

Förvirringen har en andra halva. När paketet är krypterat är allt inuti det ogenomskinligt, inklusive TCP-huvudet för den ursprungliga anslutningen. En brandvägg som inspekterar portar i det paketet tittar på det yttre huvudet, som i det inbyggda fallet inte har några portar att inspektera.

Inbyggd ESP, sedan det inkapslade alternativet

Inbyggd ESP bärs direkt som ett IP-protokoll, vilket är lika effektivt som det är opraktiskt. Effektivt eftersom det inte finns något extra huvud, och opraktiskt eftersom ingen enhet som översätter adresser och portar kan följa det. NAT-traversering finns för att lösa detta, genom att linda in ESP-paketet i UDP så att översättaren har portar att skriva om.

De två formerna är alternativa utplaceringar av samma datakanal, inte lager av en. Att tillåta inbyggd ESP tillåter inte den inkapslade formen, och att tillåta UDP 4500 tillåter inte inbyggd trafik, så en regeluppsättning måste matcha utplaceringen i stället för att av misstag täcka båda.

Upptäckt spelar också roll här. Ändpunkterna väljer mellan formerna under förhandlingen, och bytet sker vanligtvis när en NAT upptäcks mellan dem. En väg som ändras efter att tunneln upprättats kan därför flytta trafiken till en namnrymd som dina regler aldrig täckte.

Läs vilken form anslutningen faktiskt använder

Fråga ändpunkten i stället för att gissa från brandväggen. På Linux rapporterar tillståndsposten om associationen använder UDP-inkapsling och vilka portar som är inblandade. En paketfångst svarar på samma fråga från ledningen, och båda är snabbare än att läsa en regeluppsättning och hoppas.

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

Det första kommandot visar en inkapslingstyp när NAT-traversering används och ingenting när den inte gör det. Det andra visar vilken av de två formerna som faktiskt passerar gränssnittet, och det avgör diskussioner om en konfiguration som ser korrekt ut på papperet.

Motbevis hör hemma i samma steg. En regel som rapporterar noll träffar berättar att paketet aldrig nådde den, och det är en routing- eller väljarfråga, inte en brandväggsfråga.

Bekräfta sedan kontrollkanalen separat. IKE har sina egna portar och sina egna loggar, och en avslutad förhandling utan data är precis den uppdelning som den här artikeln handlar om.

Skriv regeln i rätt namnrymd

En protokollregel och en portregel är olika instruktioner, så verktyget måste uttrycka den du menar. I nftables är protokollmatchningen explicit, och det inkapslade alternativet får sin egen UDP-regel. Håll de två reglerna intill varandra så att paret syns vid granskningen.

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

Utöka inte någon av reglerna för att kompensera för en feldiagnos. En tillåt-allt för ESP-protokollet på varje gränssnitt, eller ett UDP-tillstånd från var som helst till var som helst, rättar ett symptom och tar bort den kontroll du försökte ställa in. Det smala stödda flödet räcker nästan alltid när formen är känd.

Slutligen, håll lagren rätt när tunneln fungerar och applikationen inte. Paket som kommer till gatewayen behöver fortfarande vidarebefordran, en returväg och en policy som släpper in dem, och inget av detta uttrycks av en ESP-regel. Den saknade porten förklarar ett specifikt fel, inte varje IPsec-fel. Håll regelrättelsen och routingkontrollen som två separata slutsatser.

Anteckna formen du observerade, protokollregeln du lade till och räknaren du såg efteråt. Tre rader, och nästa person kan skilja ett namnrymdsfel från ett routingfel på en minut i stället för en eftermiddag.