L2TP/IPsec కి IPsec తో పాటు UDP 1701 ఎందుకు అవసరం

IKE మరియు ESP లను అనుమతించి UDP 1701 ను అనుమతించని ఫైర్వాల్లు L2TP కనెక్షన్లను ఆధారాల సమస్యలా కనిపించే విధంగా విచ్ఛిన్నం చేస్తాయి. కారణం L2TP మొదటి దాని లోపల ప్రయాణించే రెండవ ప్రోటోకాల్ కావడం. IPsec మార్పిడిని మోసుకెళ్లి ధృవీకరిస్తుంది, L2TP తన సొంత సొరంగాన్ని UDP 1701 పై నడుపుతుంది, దాన్ని స్థానిక స్టాక్ ఇంకా పంపాలి. ప్రతి హెడర్ ఎక్కడ కనిపిస్తుందో తెలుసుకోవడం ఏ పరికరానికి ఏ నియమం కావాలో వివరిస్తుంది.

రెండు ప్రోటోకాల్లు, రెండు పోర్ట్ సెట్లు

L2TP/IPsec కనెక్షన్ UDP 500 పై IKE, అనువాదం ఉన్న చోట UDP 4500 పై NAT ట్రావర్సల్, లేని చోట IP ప్రోటోకాల్ 50 గా ESP ఉపయోగిస్తుంది. L2TP స్వయంగా UDP 1701 పై సొరంగ ప్రోటోకాల్, IPsec ప్రత్యర్థిని ధృవీకరించిన తర్వాతే అది పనిచేస్తుంది. రెండు భాగాలు వేర్వేరు విధాలుగా విఫలమవుతాయి, వాటి గురించి నివేదించే లాగ్ పంక్తులు వేర్వేరు భాగాల నుండి వస్తాయి. మొదటి సగాన్ని మాత్రమే కవర్ చేసే నియమ సెట్ చర్చలు జరిపి తర్వాత సొరంగ దశలో చనిపోయే కనెక్షన్ను ఇస్తుంది.

పోర్ట్ సంఖ్యలు రవాణా చివరి బిందువులను వివరిస్తాయి, ESP అసలు పోర్ట్ కాదు. అందుకే TCP మరియు UDP నియమాలను మాత్రమే ఇచ్చే ఫైర్వాల్ ఇంటర్ఫేస్ పూర్తి IPsec విధానాన్ని వ్యక్తపరచలేదు. ప్రోటోకాల్ 50 ను ప్రోటోకాల్గా అనుమతించాలి, UDP ను మాత్రమే ప్రస్తావించే నియమం దానితో ఎప్పటికీ సరిపోలదు.

కవచం పోర్టును వివరిస్తుంది

తీగపై, L2TP/IPsec కనెక్షన్ సాధారణంగా 500 పై IKE మరియు 4500 పై చుట్టబడిన ESP చూపిస్తుంది. UDP 1701 హెడర్ రక్షిత పేలోడ్ లోపల ఉంటుంది, అందుకే బయటి ఇంటర్ఫేస్పై క్యాప్చర్ దాన్ని చూపదు. స్థానిక హోస్ట్ ఆ డేటాగ్రామ్ను L2TP డీమన్కు ఇంకా పంపాలి, పంపడం డీక్యాప్సులేషన్ తర్వాత జరుగుతుంది. కాబట్టి 1701 నియమం ఎండ్పాయింట్ సొంత ఫైర్వాల్కే చెందుతుంది, ఏ మధ్యవర్తి పరికరం ఆ పోర్టును ఎప్పుడూ చూడకపోయినా.

ప్రాసెసింగ్ క్రమం చాలా గందరగోళాన్ని వివరిస్తుంది. స్టాక్ హోస్ట్ ఫిల్టర్ కంటే ముందు IPsec విధానాన్ని వర్తింపజేస్తే, డీక్యాప్సులేట్ చేసిన L2TP ప్యాకెట్ UDP 1701 గా సరిపోలుతుంది; క్రమం తిరగబడితే, బయటి పోర్టులను నియమ సెట్ చూస్తుంది. రెండు ప్రవర్తనలు ఆచరణలో ఉన్నాయి, అందుకే అదే నియమ సెట్ ఒక ప్లాట్ఫారమ్పై పనిచేసి మరొకదానిపై విఫలమైనట్లు కనిపిస్తుంది.

క్రమంగా మార్గాన్ని తనిఖీ చేయండి

మొదట బయటి ఇంటర్ఫేస్పై క్యాప్చర్ చేసి IKE మరియు చుట్టబడిన ESP రెండు దిశల్లో కదులుతున్నాయని నిర్ధారించండి. తర్వాత డీక్యాప్సులేట్ చేసిన ట్రాఫిక్ కోసం స్థానిక ఫైర్వాల్ కౌంటర్లను తనిఖీ చేయండి. క్రమం ముఖ్యం, ఎందుకంటే ఏమీ చూపని క్యాప్చర్ అంటే సమస్య హోస్ట్ పైన ఉందని అర్థం.

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

క్యాప్చర్ మార్పిడిలో మొదటి సగాన్ని నిర్ధారించి ప్రత్యర్థి సమాధానం ఇస్తున్నారా అని చూపిస్తుంది. నియమాల జాబితా 1701 నియమం ఉందా, ఏదైనా డ్రాప్ విధానంతో పోలిస్తే అది ఎక్కడ ఉంది అని చూపిస్తుంది. సాకెట్ జాబితా L2TP డీమన్ బంధించబడి వింటున్నట్లు నిర్ధారిస్తుంది, ఇది ఎప్పుడూ ప్రారంభం కాని సేవను మినహాయిస్తుంది. నియమాన్ని మార్చే ముందు మూడింటినీ చదవండి, ఎందుకంటే వినేవారు లేకపోవడం మరియు ఫిల్టర్ చేసిన పోర్టు వినియోగదారు నుండి ఒకే ఫిర్యాదు తెస్తాయి.

పోర్ట్ స్కాన్ చూపలేనిది

సరిగ్గా కాన్ఫిగర్ చేసిన సర్వర్పై UDP 1701 యొక్క బయటి స్కాన్ సాధారణంగా ఏమీ నివేదించదు, అదే ఆశించిన ఫలితం. పోర్టు ఇంటర్నెట్కు బహిర్గతం కాలేదు; IPsec ప్రత్యర్థిని ధృవీకరించిన తర్వాతే దాన్ని చేరుకోగలం. మూసి ఉన్న ఫలితాన్ని లోపంగా భావిస్తే మూసి ఉండాల్సిన పోర్టు తెరుచుకుంటుంది. స్కాన్ అప్లికేషన్ ట్రాఫిక్ను చూడలేనంతగానే సొరంగం లోపల కూడా చూడలేదు.

బదులుగా నిజమైన క్లయింట్తో పరీక్షించి, అది ఏ దశకు చేరుతుందో చదవండి. కనెక్షన్ చర్చలు జరిపి ఆపై ఆగిపోతే, L2TP డీమన్ లేదా స్థానిక ఫిల్టర్ అనుమానితం; అది ఎప్పుడూ చర్చలు జరపకపోతే, బయటి పోర్టులే కారణం. ఆ ఒక్క విభజన ఏ నియమం జోడించాలనే ఊహలో చాలా వరకు తొలగిస్తుంది, ప్రోటోకాల్ పొరలు దాన్ని రహస్యంగా కాకుండా ఊహించదగినదిగా చేస్తాయి.