Wêrom't L2TP/IPsec UDP 1701 nedich hat neist IPsec

Brânmuorren dy't IKE en ESP tastean mar net UDP 1701, brekke L2TP-ferbiningen op in manier dy't op in probleem mei oanmeldgegevens liket. De reden is dat L2TP in twadde protokol is dat binnen de earste reizget. IPsec draacht en ferifiearret de útwikseling, en L2TP rint syn eigen tunnel oer UDP 1701, dy't de pleatslike stapel noch altyd leverje moat. Witte wêr't elke kop ferskynt, ferklearret hokker apparaat hokker regel nedich hat.

Twa protokollen, twa poartsets

In L2TP/IPsec-ferbining brûkt IKE op UDP 500, NAT-trochgong op UDP 4500 wêr't oersetting is, en ESP as IP-protokol 50 wêr't dy der net is. L2TP sels is in tunnelprotokol op UDP 1701, en it rint neidat IPsec de partner ferifiearre hat. De beide helten mislearje oars, en de logregels dy't dêroer rapportearje komme fan ferskate komponinten. In regelset dy't allinnich de earste helte dekt, leveret in ferbining dy't ûnderhannelt en dan yn 'e tunnelfaze stjert.

Poartnûmers beskriuwe ferfierseinpunten, en ESP is hielendal gjin poart. Dêrom kin in brânmuorflak dat allinnich TCP- en UDP-regels biedt, gjin folslein IPsec-belied útdrukke. Protokol 50 moat as protokol tastien wurde, en in regel dy't allinnich UDP neamt, sil it nea treffe.

It omhulsel ferklearret de poart

Op 'e tried lit in L2TP/IPsec-ferbining normaal IKE op 500 en ynkapsele ESP op 4500 sjen. De UDP 1701-kop sit binnen de beskerme lading, dêrom lit in opname op it bûtenste flak him net sjen. De pleatslike host moat dat datagram noch altyd by de L2TP-demon leverje, en de levering bart nei it útpakken. Dêrom heart de 1701-regel by de brânmuorre fan it einpunt sels, sels as gjin tuskenbeaken de poart ea sjocht.

De ferwurkingsfolchoarder ferklearret it measte fan 'e betizing. As de stapel it IPsec-belied foar it hostfilter tapaset, wurdt it útpakte L2TP-pakket as UDP 1701 matsen; as de folchoarder omkeard is, binne de bûtenste poarten wat de regelset sjocht. Beide gedrach komt yn 'e praktyk foar, dêrom liket deselde regelset op it iene platfoarm te wurkjen en op it oare te mislearjen.

Kontrolearje it paad yn folchoarder

Meitsje earst in opname op it bûtenste flak en befêstigje dat IKE en ynkapsele ESP yn beide rjochtingen bewege. Kontrolearje dan de tellers fan 'e pleatslike brânmuorre foar it útpakte ferkear. De folchoarder is wichtich, want in opname dy't hielendal neat lit sjen, betsjut dat it probleem boppe de host sit.

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

De opname befêstiget de earste helte fan 'e útwikseling en lit sjen oft de partner antwurdet. De regellist lit sjen oft der in 1701-regel is en wêr't dy stiet tsjinoer in eventueel drop-belied. De socketlist befêstiget dat de L2TP-demon bûn is en harket, wat in tsjinst dy't nea begûn is útslút. Lês alle trije foardat jo in regel feroarje, want in ûntbrekkende harker en in filtere poart leverje identike klachten fan 'e brûker.

Wat in poartskanning net sjen kin

In eksterne skanning fan UDP 1701 tsjin in korrekt konfigurearre tsjinner rapportearret normaal neat, en dat is it ferwachte resultaat. De poart is net oan it ynternet bleatsteld; men berikt him pas neidat IPsec de partner ferifiearre hat. It sletten resultaat as in stoarning behannelje liedt ta it iepenjen fan in poart dy't ticht bliuwe moat. De skanning kin net yn 'e tunnel sjen, like min as er it ferkear fan 'e applikaasje sjen kin.

Testje ynstee mei in echte klant, en lês hokker fase hy berikt. As de ferbining ûnderhannelt en dan fêstrint, is de L2TP-demon of it pleatslike filter de fertochte; as er nea ûnderhannelt, binne de bûtenste poarten de skuldige. Dy iene splitsing hellet it measte fan 'e gis derút oer hokker regel tafoege wurde moat, en de protokolgelaachdheid makket it foarsisber ynstee fan mysterieus.