Waarom L2TP/IPsec UDP 1701 sowel as IPsec nodig het

Vuurmure wat IKE en ESP toelaat maar nie UDP 1701 nie, breek L2TP-verbindings op 'n manier wat soos 'n geloofwaardigheidsprobleem lyk. Die rede is dat L2TP 'n tweede protokol is wat binne die eerste reis. IPsec dra en verifieer die uitruiling, en L2TP hardloop sy eie tonnel oor UDP 1701, wat die plaaslike stapel steeds moet aflewer. Om te weet waar elke kop verskyn, verduidelik watter toestel watter reël nodig het.

Twee protokolle, twee poortstelle

'n L2TP/IPsec-verbinding gebruik IKE op UDP 500, NAT-deurgang op UDP 4500 waar vertaling teenwoordig is, en ESP as IP-protokol 50 waar dit nie is nie. L2TP self is 'n tonnelprotokol op UDP 1701, en dit loop nadat IPsec die eweknie verifieer het. Die twee helftes faal verskillend, en die logreëls wat daaroor rapporteer kom van verskillende komponente. 'n Reëlstel wat net die eerste helfte dek, lewer 'n verbinding wat onderhandel en dan by die tonnelstadium sterf.

Poortnommers beskryf vervoerpunte, en ESP is glad nie 'n poort nie. Daarom kan 'n vuurmuurkoppelvlak wat net TCP- en UDP-reëls bied, nie 'n volledige IPsec-beleid uitdruk nie. Protokol 50 moet as 'n protokol toegelaat word, en 'n reël wat net UDP noem, sal dit nooit pas nie.

Die omhulsel verduidelik die poort

Op die draad wys 'n L2TP/IPsec-verbinding gewoonlik IKE op 500 en ingekapselde ESP op 4500. Die UDP 1701-kop sit binne die beskermde loonvrag, en daarom wys 'n opname op die buitenste koppelvlak dit nie. Die plaaslike gasheer moet steeds daardie datagram aan die L2TP-agtergronddiens aflewer, en aflewering gebeur ná ontdoping. Die 1701-reël hoort dus op die eindpunt se eie vuurmuur, selfs wanneer geen middelkassie ooit die poort sien nie.

Die verwerkingsorde verduidelik die meeste verwarring. As die stapel die IPsec-beleid voor die gasheerfilter toepas, word die ontdopte L2TP-pakket as UDP 1701 gepas; as die orde omgekeer is, is die buitenste poorte wat die reëlstel sien. Albei gedrag kom in die praktyk voor, en daarom lyk dit of dieselfde reëlstel op een platform werk en op 'n ander faal.

Kontroleer die pad in volgorde

Neem eers die buitenste koppelvlak waar en bevestig dat IKE en ingekapselde ESP in albei rigtings beweeg. Kyk dan na die plaaslike vuurmuurtellers vir die ontdopte verkeer. Die orde maak saak, want 'n opname wat glad niks wys nie, beteken die probleem sit stroomop van die gasheer.

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

Die opname bevestig die eerste helfte van die uitruiling en wys of die eweknie antwoord. Die reëllisting wys of daar 'n 1701-reël bestaan en waar dit staan teenoor enige druppelbeleid. Die soklisting bevestig dat die L2TP-agtergronddiens gebind is en luister, wat 'n diens wat nooit begin het nie uitsluit. Lees al drie voordat jy 'n reël verander, want 'n ontbrekende luisteraar en 'n gefiltreerde poort lewer identiese klagtes van die gebruiker.

Wat 'n poortskandering nie kan wys nie

'n Eksterme skandering van UDP 1701 teen 'n korrek opgestelde bediener rapporteer gewoonlik niks, en dit is die verwagte resultaat. Die poort is nie aan die internet blootgestel nie; dit word slegs bereik nadat IPsec die eweknie verifieer het. Om die geslote resultaat as 'n fout te behandel, lei daartoe dat 'n poort oopgemaak word wat toe moet bly. Die skandering kan nie binne die tonnel sien nie, net so min as wat dit die toepassingsverkeer kan sien.

Toets eerder met 'n werklike kliënt, en lees die stadium wat dit bereik. As die verbinding onderhandel en dan vasdraai, is die L2TP-agtergronddiens of die plaaslike filter die verdagte; as dit nooit onderhandel nie, is die buitenste poorte dit. Daardie enkele skeiding verwyder die meeste van die raaiery oor watter reël om by te voeg, en die protokolgelaagdheid maak dit voorspelbaar eerder as misterieus.