Pse L2TP/IPsec kërkon UDP 1701 përveç IPsec
L2TP është një protokoll i dytë që udhëton brenda të parit, prandaj pika fundore duhet të dorëzojë gjithsesi UDP 1701 pas dekapsulimit, edhe kur asnjë pajisje ndërmjetëse nuk e sheh.
Muret e zjarrit që lejojnë IKE dhe ESP por jo UDP 1701 i prishin lidhjet L2TP në një mënyrë që duket si problem kredencialesh. Arsyeja është se L2TP është një protokoll i dytë që udhëton brenda të parit. IPsec transporton dhe vërteton shkëmbimin, dhe L2TP drejton tunelin e vet mbi UDP 1701, të cilin staku lokal duhet ta dorëzojë gjithsesi. Të dish ku shfaqet çdo krye shpjegon se cila pajisje ka nevojë për cilën rregull.
Dy protokolle, dy grupe portesh
Një lidhje L2TP/IPsec përdor IKE në UDP 500, kalimin NAT në UDP 4500 aty ku ka përkthim, dhe ESP si protokoll IP 50 aty ku nuk ka. Vetë L2TP është një protokoll tuneli në UDP 1701 dhe punon pasi IPsec ka vërtetuar palën. Dy gjysmat dështojnë ndryshe, dhe rreshtat e regjistrit që raportojnë për to vijnë nga komponentë të ndryshëm. Një grup rregullash që mbulon vetëm gjysmën e parë prodhon një lidhje që negocion dhe më pas vdes në fazën e tunelit.
Numrat e porteve përshkruajnë pikat fundore të transportit, dhe ESP nuk është fare port. Prandaj një ndërfaqe muri zjarri që ofron vetëm rregulla TCP dhe UDP nuk mund të shprehë një politikë të plotë IPsec. Protokolli 50 duhet të lejohet si protokoll, dhe një rregull që përmend vetëm UDP nuk do të përputhet kurrë me të.
Mbështjellja shpjegon portin
Në rrjet, një lidhje L2TP/IPsec zakonisht tregon IKE në 500 dhe ESP të mbështjellë në 4500. Kryet UDP 1701 ndodhet brenda ngarkesës së mbrojtur, prandaj një kapje në ndërfaqen e jashtme nuk e tregon. Host-i lokal duhet ta dorëzojë gjithsesi atë datagram te demoni L2TP, dhe dorëzimi ndodh pas dekapsulimit. Prandaj rregulli 1701 i takon murit të zjarrit të vetë pikës fundore, edhe kur asnjë pajisje ndërmjetëse nuk e sheh kurrë portin.
Rendi i përpunimit shpjegon pjesën më të madhe të konfuzionit. Nëse staku zbaton politikën IPsec përpara filtrit të host-it, paketa L2TP e dekapsuluar përputhet si UDP 1701; nëse rendi është i kundërt, portet e jashtme janë ajo që sheh grupi i rregullave. Të dyja sjelljet ekzistojnë në praktikë, prandaj i njëjti grup rregullash duket se punon në një platformë dhe dështon në një tjetër.
Kontrolloni rrugën sipas radhës
Së pari kapni ndërfaqen e jashtme dhe konfirmoni se IKE dhe ESP i mbështjellë lëvizin në të dy drejtimet. Më pas kontrolloni numëruesit e murit të zjarrit lokal për trafikun e dekapsuluar. Rendi ka rëndësi, sepse një kapje që nuk tregon asgjë do të thotë se problemi ndodhet mbi host-in.
sudo tcpdump -ni eth0 'udp port 500 or udp port 4500'
sudo nft list ruleset | grep -i -A2 1701
sudo ss -lunp | grep 1701
Kapja konfirmon gjysmën e parë të shkëmbimit dhe tregon nëse pala përgjigjet. Lista e rregullave tregon nëse ekziston një rregull 1701 dhe ku qëndron në raport me çdo politikë hedhjeje. Lista e soketave konfirmon se demoni L2TP është i lidhur dhe dëgjon, gjë që përjashton një shërbim që nuk u nis kurrë. Lexoni të treja përpara se të ndryshoni një rregull, sepse një dëgjues që mungon dhe një port i filtruar prodhojnë ankesa identike nga përdoruesi.
Çfarë nuk mund të tregojë një skanim portesh
Një skanim i jashtëm i UDP 1701 kundër një serveri të konfiguruar saktë zakonisht nuk raporton asgjë, dhe ky është rezultati i pritur. Porti nuk është i ekspozuar në internet; ai arrihet vetëm pasi IPsec ka vërtetuar palën. Trajtimi i rezultatit të mbyllur si defekt çon në hapjen e një porti që duhet të mbetet i mbyllur. Skanimi nuk mund të shohë brenda tunelit më shumë sesa mund të shohë trafikun e aplikacionit.
Në vend të kësaj provoni me një klient real, dhe lexoni deri në cilën fazë arrin. Nëse lidhja negocion dhe më pas ngec, i dyshuari është demoni L2TP ose filtri lokal; nëse nuk negocion kurrë, portet e jashtme janë fajtore. Ai ndarje i vetëm heq pjesën më të madhe të hamendjes se cili rregull duhet shtuar, dhe shtresimi i protokollit e bën atë të parashikueshëm në vend të misterioz.