Hvorfor L2TP/IPsec har brug for UDP 1701 ud over IPsec

Firewalls, der tillader IKE og ESP, men ikke UDP 1701, bryder L2TP-forbindelser på en måde, der ligner et legitimationsproblem. Årsagen er, at L2TP er en anden protokol, der rejser inde i den første. IPsec bærer og autentificerer udvekslingen, og L2TP kører sin egen tunnel over UDP 1701, som den lokale stak stadig skal levere. At vide, hvor hver header optræder, forklarer, hvilken enhed der har brug for hvilken regel.

To protokoller, to sæt porte

En L2TP/IPsec-forbindelse bruger IKE på UDP 500, NAT-gennemgang på UDP 4500 hvor der er oversættelse, og ESP som IP-protokol 50 hvor der ikke er. L2TP selv er en tunnelprotokol på UDP 1701, og den kører, efter at IPsec har autentificeret modparten. De to halvdele fejler forskelligt, og de loglinjer, der rapporterer om dem, kommer fra forskellige komponenter. Et regelsæt, der kun dækker den første halvdel, giver en forbindelse, der forhandler og derefter dør i tunnelstadiet.

Portnumre beskriver transportendepunkter, og ESP er slet ikke en port. Derfor kan en firewallflade, der kun tilbyder TCP- og UDP-regler, ikke udtrykke en fuld IPsec-politik. Protokol 50 skal tillades som protokol, og en regel, der kun nævner UDP, vil aldrig matche den.

Indpakningen forklarer porten

På ledningen viser en L2TP/IPsec-forbindelse normalt IKE på 500 og indkapslet ESP på 4500. UDP 1701-headeren sidder inde i den beskyttede nyttelast, og derfor viser en optagelse på den ydre grænseflade den ikke. Den lokale vært skal stadig levere den datagram til L2TP-dæmonen, og leveringen sker efter dekapsulering. Reglen for 1701 hører derfor til endepunktets egen firewall, selv når ingen mellemboks nogensinde ser porten.

Rækkefølgen af behandlingen forklarer det meste af forvirringen. Hvis stakken anvender IPsec-politikken før værtens filter, matches den dekapsulerede L2TP-pakke som UDP 1701; hvis rækkefølgen er omvendt, er det de ydre porte, som regelsættet ser. Begge adfærd findes i praksis, og derfor ser det samme regelsæt ud til at virke på én platform og fejle på en anden.

Kontroller stien i rækkefølge

Optag den ydre grænseflade først, og bekræft, at IKE og indkapslet ESP bevæger sig i begge retninger. Kontroller derefter værtens firewalltællere for den dekapsulerede trafik. Rækkefølgen er vigtig, fordi en optagelse, der slet ikke viser noget, betyder, at problemet sidder oven for værten.

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

Optagelsen bekræfter den første halvdel af udvekslingen og viser, om modparten svarer. Regellisten viser, om der findes en regel for 1701, og hvor den ligger i forhold til en eventuel drop-politik. Socketlisten bekræfter, at L2TP-dæmonen er bundet og lytter, hvilket udelukker en tjeneste, der aldrig startede. Læs alle tre, før du ændrer en regel, fordi en manglende lytter og en filtreret port giver identiske klager fra brugeren.

Hvad en portscanning ikke kan vise

En ekstern scanning af UDP 1701 mod en korrekt konfigureret server rapporterer normalt intet, og det er det forventede resultat. Porten er ikke eksponeret mod internettet; den nås kun, efter at IPsec har autentificeret modparten. Behandler man det lukkede resultat som en fejl, åbner man en port, der burde forblive lukket. Scanningen kan ikke se ind i tunnelen, lige så lidt som den kan se applikationens trafik.

Test i stedet med en rigtig klient, og læs det stadie, den når. Hvis forbindelsen forhandler og derefter går i stå, er det L2TP-dæmonen eller det lokale filter, der er mistænkt; hvis den aldrig forhandler, er det de ydre porte. Den ene opdeling fjerner det meste af gætteriet om, hvilken regel der skal tilføjes, og protokolopdelingen gør det forudsigeligt i stedet for mystisk.