Zašto je L2TP/IPsec-u potreban UDP 1701 uz IPsec

Vatrozidi koji dopuštaju IKE i ESP ali ne i UDP 1701 prekidaju L2TP veze na način koji izgleda kao problem s vjerodajnicama. Razlog je to što je L2TP drugi protokol koji putuje unutar prvog. IPsec prenosi i provjerava razmjenu, a L2TP vodi vlastiti tunel preko UDP 1701, koji lokalni stog ipak mora dostaviti. Znati gdje se pojavljuje svako zaglavlje objašnjava kojem uređaju treba koje pravilo.

Dva protokola, dva skupa portova

L2TP/IPsec veza koristi IKE na UDP 500, NAT prolaz na UDP 4500 gdje je prisutno prevođenje i ESP kao IP protokol 50 gdje nije. Sam L2TP je tunelski protokol na UDP 1701 i radi nakon što IPsec provjeri partnera. Dvije polovice otkazuju na različite načine, a zapisi u dnevniku koji o njima izvještavaju dolaze iz različitih komponenti. Skup pravila koji pokriva samo prvu polovicu stvara vezu koja pregovara i zatim umire u fazi tunela.

Brojevi portova opisuju transportne krajnje točke, a ESP uopće nije port. Zato sučelje vatrozida koje nudi samo TCP i UDP pravila ne može izraziti potpunu IPsec politiku. Protokol 50 mora biti dopušten kao protokol, a pravilo koje spominje samo UDP nikada se neće podudariti s njim.

Omotač objašnjava port

Na mreži L2TP/IPsec veza obično pokazuje IKE na 500 i zapakirani ESP na 4500. Zaglavlje UDP 1701 nalazi se unutar zaštićenog tereta, zato ga snimanje na vanjskom sučelju ne pokazuje. Lokalni host ipak mora dostaviti taj datagram L2TP demonu, a dostava se događa nakon dekapsulacije. Pravilo 1701 zato pripada vatrozidu same krajnje točke, čak i kada nijedan posredni uređaj nikada ne vidi taj port.

Redoslijed obrade objašnjava većinu zabune. Ako stog primijeni IPsec politiku prije filtra hosta, dekapsulirani L2TP paket podudara se kao UDP 1701; ako je redoslijed obrnut, vanjski portovi su ono što skup pravila vidi. Oba se ponašanja javljaju u praksi, zato se čini da isti skup pravila radi na jednoj platformi, a pada na drugoj.

Provjerite put po redu

Prvo snimite vanjsko sučelje i potvrdite da se IKE i zapakirani ESP kreću u oba smjera. Zatim provjerite lokalne brojače vatrozida za dekapsulirani promet. Redoslijed je važan jer snimanje koje ne pokazuje ništa znači da problem leži uzvodno od hosta.

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

Snimanje potvrđuje prvu polovicu razmjene i pokazuje odgovara li partner. Popis pravila pokazuje postoji li pravilo 1701 i gdje stoji u odnosu na bilo koju politiku odbacivanja. Popis socketa potvrđuje da je L2TP demon vezan i da sluša, što isključuje servis koji nikada nije pokrenut. Pročitajte sva tri prije promjene pravila, jer slušatelj koji nedostaje i filtrirani port daju identične pritužbe korisnika.

Što skeniranje portova ne može pokazati

Vanjsko skeniranje UDP 1701 na ispravno konfiguriran poslužitelj obično ne prijavljuje ništa i to je očekivani rezultat. Port nije izložen internetu; do njega se dolazi samo nakon što IPsec provjeri partnera. Ako zatvoreni rezultat tretirate kao kvar, otvorit ćete port koji bi trebao ostati zatvoren. Skeniranje ne može vidjeti unutar tunela jednako kao što ne može vidjeti promet aplikacije.

Umjesto toga testirajte pravim klijentom i pročitajte do koje faze dolazi. Ako veza pregovara i zatim se zaglavi, sumnjivci su L2TP demon ili lokalni filtar; ako nikada ne pregovara, vanjski su portovi krivi. Ta jedna podjela uklanja većinu nagađanja o tome koje pravilo dodati, a slojevitost protokola čini to predvidljivim, a ne tajanstvenim.