Miksi L2TP/IPsec tarvitsee UDP 1701:n IPsecin lisäksi

Palomuurit, jotka sallivat IKE:n ja ESP:n mutta eivät UDP 1701:tä, rikkovat L2TP-yhteydet tavalla, joka näyttää tunnistetieto-ongelmalta. Syynä on, että L2TP on toinen protokolla, joka kulkee ensimmäisen sisällä. IPsec kuljettaa ja todentaa vaihdon, ja L2TP ajaa oman tunnelinsa UDP 1701:n päällä, joka paikallisen pinon on silti toimitettava. Tieto siitä, missä kukin otsake esiintyy, selittää, mikä laite tarvitsee minkä säännön.

Kaksi protokollaa, kaksi porttijoukkoa

L2TP/IPsec-yhteys käyttää IKE:tä UDP 500:ssa, NAT-läpäisyä UDP 4500:ssa siellä missä käännös on, ja ESP:tä IP-protokollana 50 siellä missä sitä ei ole. L2TP itsessään on tunneliprotokolla UDP 1701:ssä, ja se käynnistyy sen jälkeen, kun IPsec on todentanut vastapuolen. Kaksi puoliskoa epäonnistuvat eri tavoin, ja niistä raportoivat lokirivit tulevat eri komponenteista. Vain ensimmäisen puoliskon kattava sääntöjoukko tuottaa yhteyden, joka neuvottelee ja kuolee sitten tunnelivaiheessa.

Porttinumerot kuvaavat kuljetuksen päätepisteitä, eikä ESP ole portti lainkaan. Siksi palomuurin käyttöliittymä, joka tarjoaa vain TCP- ja UDP-säännöt, ei voi ilmaista täydellistä IPsec-käytäntöä. Protokolla 50 on sallittava protokollana, eikä vain UDP:n mainitseva sääntö osu siihen koskaan.

Kääre selittää portin

Verkossa L2TP/IPsec-yhteys näyttää yleensä IKE:n 500:ssa ja kapseloidun ESP:n 4500:ssa. UDP 1701 -otsake on suojatun hyötykuorman sisällä, minkä vuoksi ulomman liitännän kaappaus ei näytä sitä. Paikallisen isäntäkoneen on silti toimitettava tämä datagrammi L2TP-taustainohjelmalle, ja toimitus tapahtuu purkamisen jälkeen. Siksi 1701-sääntö kuuluu päätepisteen omaan palomuuriin, vaikka mikään välilaite ei näkisi porttia koskaan.

Käsittelyjärjestys selittää suurimman osan hämmennystä. Jos pino soveltaa IPsec-käytäntöä ennen isännän suodatinta, purettu L2TP-paketti täsmätään UDP 1701:nä; jos järjestys on päinvastainen, sääntöjoukko näkee ulommat portit. Molemmat käyttäytymiset esiintyvät käytännössä, siksi sama sääntöjoukko näyttää toimivan yhdellä alustalla ja epäonnistuvan toisella.

Tarkista polku järjestyksessä

Kaappaa ensin ulompi liitäntä ja varmista, että IKE ja kapseloitu ESP liikkuvat molempiin suuntiin. Tarkista sitten paikallisen palomuurin laskurit puretun liikenteen osalta. Järjestys on tärkeä, koska kaappaus, joka ei näytä yhtään mitään, tarkoittaa, että ongelma on isäntää ylempänä.

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

Kaappaus vahvistaa vaihdon ensimmäisen puoliskon ja näyttää, vastaako vastapuoli. Sääntöluettelo näyttää, onko 1701-sääntö olemassa ja missä se on suhteessa mihin tahansa hylkäyskäytäntöön. Pistokeluettelo vahvistaa, että L2TP-taustainohjelma on sidottu ja kuuntelee, mikä sulkee pois palvelun, joka ei koskaan käynnistynyt. Lue kaikki kolme ennen säännön muuttamista, koska puuttuva kuuntelija ja suodatettu portti tuottavat käyttäjältä saman valituksen.

Mitä porttiskannaus ei voi näyttää

UDP 1701:n ulkoinen skannaus oikein konfiguroitua palvelinta vastaan ei yleensä ilmoita mitään, ja se on odotettu tulos. Portti ei ole altistettu internetille; siihen päästään vain sen jälkeen, kun IPsec on todentanut vastapuolen. Suljetun tuloksen käsitteleminen vikana johtaa portin avaamiseen, jonka pitäisi pysyä suljettuna. Skannaus ei näe tunnelin sisään sen enempää kuin se näkee sovelluksen liikennettä.

Testaa sen sijaan oikealla asiakkaalla ja lue, mille vaiheelle se pääsee. Jos yhteys neuvottelee ja juuttuu sitten, epäilty on L2TP-taustainohjelma tai paikallinen suodatin; jos se ei neuvottele koskaan, syy on ulommissa porteissa. Tämä yksi jako poistaa suurimman osan arvailusta siitä, mikä sääntö lisätään, ja protokollien kerrostaminen tekee siitä ennustettavaa mysteerin sijaan.