Hvorfor L2TP/IPsec trenger UDP 1701 i tillegg til IPsec

Brannmurer som tillater IKE og ESP, men ikke UDP 1701, bryter L2TP-tilkoblinger på en måte som ser ut som et problem med påloggingsinformasjon. Årsaken er at L2TP er en andre protokoll som reiser inne i den første. IPsec bærer og autentiserer utvekslingen, og L2TP kjører sin egen tunnel over UDP 1701, som den lokale stakken fortsatt må levere. Å vite hvor hver header dukker opp forklarer hvilken enhet som trenger hvilken regel.

To protokoller, to portsett

En L2TP/IPsec-tilkobling bruker IKE på UDP 500, NAT-gjennomgang på UDP 4500 der det finnes oversettelse, og ESP som IP-protokoll 50 der det ikke gjør det. L2TP selv er en tunnelprotokoll på UDP 1701, og den kjører etter at IPsec har autentisert motparten. De to halvdelene feiler ulikt, og logglinjene som rapporterer om dem kommer fra forskjellige komponenter. Et regelsett som bare dekker den første halvdelen gir en tilkobling som forhandler og deretter dør i tunnelstadiet.

Portnumre beskriver transportendepunkter, og ESP er ikke en port i det hele tatt. Derfor kan et brannmur-grensesnitt som bare tilbyr TCP- og UDP-regler ikke uttrykke en fullstendig IPsec-policy. Protokoll 50 må tillates som protokoll, og en regel som bare nevner UDP vil aldri treffe den.

Innpakningen forklarer porten

På ledningen viser en L2TP/IPsec-tilkobling vanligvis IKE på 500 og innkapslet ESP på 4500. UDP 1701-headeren sitter inne i den beskyttede lasten, derfor viser ikke en fangst på det ytre grensesnittet den. Den lokale verten må fortsatt levere den datagrammen til L2TP-demonen, og leveringen skjer etter dekapsulering. Regelen for 1701 hører derfor til endepunktets egen brannmur, selv når ingen mellomliggende boks noen gang ser porten.

Rekkefølgen i behandlingen forklarer det meste av forvirringen. Hvis stakken bruker IPsec-policyen før vertens filter, matches den dekapsulerte L2TP-pakken som UDP 1701; hvis rekkefølgen er omvendt, er det de ytre portene regelsettet ser. Begge atferdene finnes i praksis, derfor ser det samme regelsettet ut til å virke på én plattform og feile på en annen.

Kontroller stien i rekkefølge

Ta først en fangst på det ytre grensesnittet og bekreft at IKE og innkapslet ESP beveger seg i begge retninger. Sjekk deretter vertens brannmurtellere for den dekapsulerte trafikken. Rekkefølgen er viktig, fordi en fangst som ikke viser noe som helst betyr at problemet ligger ovenfor verten.

sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701

Fangsten bekrefter den første halvdelen av utvekslingen og viser om motparten svarer. Regellisten viser om det finnes en regel for 1701 og hvor den står i forhold til en eventuell dropp-policy. Socketlisten bekrefter at L2TP-demonen er bundet og lytter, noe som utelukker en tjeneste som aldri startet. Les alle tre før du endrer en regel, fordi en manglende lytter og en filtrert port gir identiske klager fra brukeren.

Hva en portskanning ikke kan vise

En ekstern skanning av UDP 1701 mot en riktig konfigurert server rapporterer vanligvis ingenting, og det er det forventede resultatet. Porten er ikke eksponert mot internett; den nås bare etter at IPsec har autentisert motparten. Å behandle det lukkede resultatet som en feil fører til at man åpner en port som burde forbli lukket. Skanningen kan ikke se inn i tunnelen noe mer enn den kan se applikasjonens trafikk.

Test i stedet med en ekte klient, og les hvilket stadium den når. Hvis tilkoblingen forhandler og deretter stopper, er L2TP-demonen eller det lokale filteret mistenkt; hvis den aldri forhandler, er det de ytre portene. Den ene inndelingen fjerner det meste av gjettingen om hvilken regel som skal legges til, og protokollagene gjør det forutsigbart i stedet for mystisk.