Kvifor L2TP/IPsec treng UDP 1701 i tillegg til IPsec

Brannmurar som tillèt IKE og ESP, men ikkje UDP 1701, bryt L2TP-tilkoplingar på ein måte som ser ut som eit problem med påloggingsinformasjon. Årsaka er at L2TP er ein andre protokoll som reiser inne i den første. IPsec ber og autentiserer utvekslinga, og L2TP køyrer sin eigen tunnel over UDP 1701, som den lokale stakken framleis må levere. Å vite kvar kvar header dukkar opp forklarer kva eining som treng kva regel.

To protokollar, to portsett

Ei L2TP/IPsec-tilkopling brukar IKE på UDP 500, NAT-gjennomgang på UDP 4500 der det finst omsetjing, og ESP som IP-protokoll 50 der det ikkje gjer det. L2TP sjølv er ein tunnelprotokoll på UDP 1701, og han køyrer etter at IPsec har autentisert motparten. Dei to helftene feilar ulikt, og logglinjene som rapporterer om dei kjem frå ulike komponentar. Eit regelsett som berre dekkjer den første helfta gjev ei tilkopling som forhandlar og deretter døyr i tunnelstadiet.

Portnummer skildrar transportendepunkt, og ESP er ikkje ein port i det heile. Difor kan eit brannmur-grensesnitt som berre tilbyr TCP- og UDP-reglar ikkje uttrykkje ein fullstendig IPsec-politikk. Protokoll 50 må tillatast som protokoll, og ein regel som berre nemner UDP vil aldri treffe han.

Innpakkinga forklarer porten

På leidninga viser ei L2TP/IPsec-tilkopling vanlegvis IKE på 500 og innkapsla ESP på 4500. UDP 1701-headeren sit inne i den verna lasta, difor viser ikkje ein fangst på det ytre grensesnittet han. Den lokale verten må framleis levere den datagrammen til L2TP-demonen, og leveringa skjer etter dekapsulering. Regelen for 1701 høyrer difor til brannmuren til endepunktet sjølv, sjølv når ingen mellomliggjande boks nokon gong ser porten.

Rekkjefylgja i handsaminga forklarer det meste av forvirringa. Viss stakken brukar IPsec-politikken før filteret til verten, vert den dekapsulerte L2TP-pakken matcha som UDP 1701; viss rekkjefylgja er omvendt, er det dei ytre portane regelsettet ser. Begge åtferdene finst i praksis, difor ser det same regelsettet ut til å verke på éin plattform og feile på ein annan.

Kontroller stien i rekkjefylgje

Ta først ein fangst på det ytre grensesnittet og stadfest at IKE og innkapsla ESP bevegar seg i begge retningar. Sjekk deretter brannmurteljarane til verten for den dekapsulerte trafikken. Rekkjefylgja er viktig, fordi ein fangst som ikkje viser noko som helst tyder på at problemet ligg ovanfor 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 stadfestar den første helfta av utvekslinga og viser om motparten svarar. Regellista viser om det finst ein regel for 1701 og kvar han står i høve til ein eventuell dropp-politikk. Socketlista stadfestar at L2TP-demonen er bunden og lyttar, noko som utelukkar ein teneste som aldri starta. Les alle tre før du endrar ein regel, fordi ein manglande lyttar og ein filtrert port gjev identiske klager frå brukaren.

Kva ein portskanning ikkje kan vise

Ein ekstern skanning av UDP 1701 mot ein rett konfigurert tenar rapporterer vanlegvis ingenting, og det er det forventa resultatet. Porten er ikkje eksponert mot internett; han er berre nåbar etter at IPsec har autentisert motparten. Å handsame det lukka resultatet som ein feil fører til at ein opnar ein port som burde halde seg lukka. Skanninga kan ikkje sjå inn i tunnelen noko meir enn ho kan sjå trafikken til applikasjonen.

Test i staden med ein ekte klient, og les kva stadium han når. Viss tilkoplinga forhandlar og deretter stoppar, er L2TP-demonen eller det lokale filteret mistenkt; viss ho aldri forhandlar, er det dei ytre portane. Den eine inndelinga fjernar det meste av gjettinga om kva regel som skal leggjast til, og protokollaga gjer det føreseieleg i staden for mystisk.