Zakaj L2TP/IPsec potrebuje UDP 1701 poleg IPsec

Požarni zidovi, ki dovoljujejo IKE in ESP, ne pa UDP 1701, prekinejo povezave L2TP na način, ki je videti kot težava s poverilnicami. Razlog je, da je L2TP drugi protokol, ki potuje znotraj prvega. IPsec prenaša in overja izmenjavo, L2TP pa vodi svoj predor prek UDP 1701, ki ga mora lokalni sklad vseeno dostaviti. Vedeti, kje se pojavi vsaka glava, pojasni, katera naprava potrebuje katero pravilo.

Dva protokola, dva niza vrat

Povezava L2TP/IPsec uporablja IKE na UDP 500, prehod NAT na UDP 4500 tam, kjer je prevajanje, in ESP kot protokol IP 50 tam, kjer ga ni. Sam L2TP je predorski protokol na UDP 1701 in deluje po tem, ko IPsec overi partnerja. Obe polovici odpovedujeta različno, vrstice dnevnika, ki poročajo o njima, pa prihajajo iz različnih komponent. Nabor pravil, ki pokriva samo prvo polovico, ustvari povezavo, ki se pogaja in nato umre v fazi predora.

Številke vrat opisujejo transportne končne točke, ESP pa sploh ni vrata. Zato vmesnik požarnega zidu, ki ponuja samo pravila TCP in UDP, ne more izraziti celotne politike IPsec. Protokol 50 mora biti dovoljen kot protokol, pravilo, ki omenja samo UDP, pa se z njim nikoli ne bo ujemalo.

Ovoj pojasni vrata

Na omrežju povezava L2TP/IPsec običajno pokaže IKE na 500 in zapakiran ESP na 4500. Glava UDP 1701 je znotraj zaščitenega tovora, zato je zajem na zunanjem vmesniku ne pokaže. Lokalni gostitelj mora to datagram še vedno dostaviti demonu L2TP, dostava pa se zgodi po dekapsulaciji. Zato pravilo 1701 sodi na požarni zid same končne točke, tudi kadar nobena vmesna naprava nikoli ne vidi vrat.

Vrstni red obdelave pojasni večino zmede. Če sklad uporabi politiko IPsec pred filtrom gostitelja, se dekapsulirani paket L2TP ujame kot UDP 1701; če je vrstni red obrnjen, so zunanja vrata tisto, kar vidi nabor pravil. Obe vedenji obstajata v praksi, zato se zdi, da isti nabor pravil deluje na eni platformi in odpove na drugi.

Preverite pot po vrsti

Najprej zajemite zunanji vmesnik in potrdite, da se IKE in zapakiran ESP premikata v obe smeri. Nato preverite števce lokalnega požarnega zidu za dekapsulirani promet. Vrstni red je pomemben, ker zajem, ki ne pokaže ničesar, pomeni, da je težava višje od gostitelja.

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

Zajem potrdi prvo polovico izmenjave in pokaže, ali partner odgovarja. Seznam pravil pokaže, ali pravilo 1701 obstaja in kje stoji glede na kakršno koli politiko zavračanja. Seznam vtičnic potrdi, da je demon L2TP vezan in posluša, kar izključi storitev, ki se ni nikoli zagnala. Preberite vse tri, preden spremenite pravilo, ker manjkajoči poslušalec in filtrirana vrata dasta enake pritožbe uporabnika.

Česa skeniranje vrat ne more pokazati

Zunanje skeniranje UDP 1701 proti pravilno nastavljenemu strežniku običajno ne poroča o ničemer in to je pričakovani rezultat. Vrata niso izpostavljena internetu; do njih pridemo šele po tem, ko IPsec overi partnerja. Če zaprt rezultat obravnavamo kot okvaro, odpremo vrata, ki bi morala ostati zaprta. Skeniranje ne vidi v notranjost predora nič bolj, kot ne vidi prometa aplikacije.

Namesto tega preizkusite z resničnim odjemalcem in preberite, do katere faze pride. Če se povezava pogaja in nato obstane, sta sumljiva demon L2TP ali lokalni filter; če se nikoli ne pogaja, so kriva zunanja vrata. Ta ena razdelitev odpravi večino ugibanj o tem, katero pravilo dodati, in plastenje protokolov naredi stvar predvidljivo namesto skrivnostno.