Kāpēc L2TP/IPsec papildus IPsec ir nepieciešams UDP 1701

Ugunsmūri, kas atļauj IKE un ESP, bet ne UDP 1701, pārtrauc L2TP savienojumus tā, ka tas izskatās pēc akreditācijas datu problēmas. Iemesls ir tāds, ka L2TP ir otrs protokols, kas ceļo pirmā iekšienē. IPsec pārvadā un autentificē apmaiņu, un L2TP darbina savu tuneli virs UDP 1701, kas vietējam stekam joprojām ir jāpiegādā. Zināšana, kur parādās katra galvene, izskaidro, kurai ierīcei kāds noteikums ir vajadzīgs.

Divi protokoli, divas portu kopas

L2TP/IPsec savienojums izmanto IKE uz UDP 500, NAT šķērsošanu uz UDP 4500 tur, kur ir tulkošana, un ESP kā IP protokolu 50 tur, kur tās nav. Pats L2TP ir tuneļa protokols uz UDP 1701, un tas darbojas pēc tam, kad IPsec ir autentificējis partneri. Abas puses neizdodas atšķirīgi, un žurnāla rindas, kas par tām ziņo, nāk no dažādām komponentēm. Noteikumu kopa, kas aptver tikai pirmo pusi, rada savienojumu, kas pārrunā un pēc tam mirst tuneļa posmā.

Portu numuri apraksta transporta galapunktus, un ESP nemaz nav ports. Tāpēc ugunsmūra saskarne, kas piedāvā tikai TCP un UDP noteikumus, nevar izteikt pilnu IPsec politiku. Protokols 50 ir jāatļauj kā protokols, un noteikums, kas min tikai UDP, ar to nekad nesakritīs.

Ietinums izskaidro portu

Tīklā L2TP/IPsec savienojums parasti parāda IKE uz 500 un iesaiņotu ESP uz 4500. UDP 1701 galvene atrodas aizsargātās kravas iekšienē, tāpēc uzņemšana ārējā saskarnē to neparāda. Vietējam resursdatoram šis datagramma joprojām ir jāpiegādā L2TP dēmonam, un piegāde notiek pēc dekapsulācijas. Tāpēc noteikums par 1701 pieder paša galapunkta ugunsmūrim, pat ja neviena starpniekierīce portu nekad neredz.

Apstrādes secība izskaidro lielāko daļu apjukuma. Ja steks IPsec politiku piemēro pirms resursdatora filtra, dekapsulētā L2TP pakete tiek saskaņota kā UDP 1701; ja secība ir pretēja, ārējie porti ir tas, ko redz noteikumu kopa. Abas uzvedības pastāv praksē, tāpēc šķiet, ka viena un tā pati noteikumu kopa darbojas vienā platformā un neizdodas citā.

Pārbaudiet ceļu secībā

Vispirms uzņemiet ārējo saskarni un apstipriniet, ka IKE un iesaiņotais ESP kustas abos virzienos. Pēc tam pārbaudiet vietējā ugunsmūra skaitītājus dekapsulētajai plūsmai. Secība ir svarīga, jo uzņemšana, kas neko neparāda, nozīmē, ka problēma ir augstāk par resursdatoru.

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

Uzņemšana apstiprina apmaiņas pirmo pusi un parāda, vai partneris atbild. Noteikumu saraksts parāda, vai pastāv noteikums par 1701 un kur tas atrodas attiecībā pret jebkuru nomešanas politiku. Ligzdu saraksts apstiprina, ka L2TP dēmons ir piesaistīts un klausās, kas izslēdz pakalpojumu, kas nekad netika palaists. Izlasiet visus trīs pirms noteikuma maiņas, jo trūkstošs klausītājs un filtrēts ports rada identiskas lietotāja sūdzības.

Ko portu skenēšana nevar parādīt

Ārēja UDP 1701 skenēšana pret pareizi konfigurētu serveri parasti neko neziņo, un tas ir gaidītais rezultāts. Ports nav pakļauts internetam; tam var piekļūt tikai pēc tam, kad IPsec ir autentificējis partneri. Aizvērto rezultātu uzskatot par bojājumu, tiek atvērts ports, kam vajadzētu palikt aizvērtam. Skenēšana nevar redzēt tuneļa iekšienē tāpat, kā tā nevar redzēt lietojumprogrammas plūsmu.

Tā vietā pārbaudiet ar īstu klientu un izlasiet, līdz kuram posmam tas nonāk. Ja savienojums pārrunā un pēc tam iestrēgst, aizdomās turamais ir L2TP dēmons vai vietējais filtrs; ja tas nekad nepārrunā, vainīgi ir ārējie porti. Šis vienīgais dalījums novērš lielāko daļu minējumu par to, kurš noteikums jāpievieno, un protokolu slāņošana padara to paredzamu, nevis noslēpumainu.