NAT ద్వారా L2TP/IPsec: నిజంగా ఏమి విరిగిపోతుంది మరియు ఎందుకు

NAT L2TP/IPsecని విరుస్తుంది అనే వాదన సగం నిజం, అందువల్ల నిష్ప్రయోజనం. చిరునామా అనువాదం సాధారణం, NAT traversal దాన్ని దాటడానికే ఉంది, మరియు ప్రతిరోజూ లక్షలాది క్లయింట్లు రౌటర్ వెనుక నుండి కనెక్ట్ అవుతాయి. విరిగేది ఒక నిర్దిష్ట మార్పిడి యొక్క నిర్దిష్ట దశ: IKE ఎప్పటికీ సమాధానం పొందదు, ఒకే ప్రోటోకాల్కు మాత్రమే అనుమతించే విధానం ద్వారా ఎన్క్యాప్సులేటెడ్ టన్నెల్ పారవేయబడుతుంది, లేదా టన్నెల్ నిష్క్రియంగా ఉన్నప్పుడు మ్యాపింగ్ గడువు ముగుస్తుంది. మీరు ఏ దశలో ఉన్నారో తెలిసిన తర్వాత, పరిష్కారం సాధారణంగా ఒక నియమం లేదా keepalive, కొత్త VPN డిజైన్ కాదు.

పురాణమే తప్పు ప్రశ్న

ఉపయోగకరమైన ప్రశ్న “NAT దీన్ని విరుస్తుందా” అని కాదు, “మార్పిడిలో ఏ భాగం అనువదించబడుతుంది, అనువదించే పరికరం దానితో ఏమి చేస్తుంది” అని. L2TP/IPsec పొరల ప్రోటోకాల్: IKE చర్చలు జరుపుతుంది, ESP రక్షిస్తుంది, మరియు L2TP ఆ రక్షణ లోపల PPP మోస్తుంది. చిరునామా అనువాదం ప్రతి పొరపై వేర్వేరుగా ప్రభావం చూపుతుంది, లోప సంభాషణకు బదులు చర్చల దశను చూస్తే వైఫల్య సంకేతాలను వేరుగా గుర్తించవచ్చు.

విజయవంతంగా వెబ్ బ్రౌజ్ చేసే రౌటర్ మూల పోర్ట్ అనువాదంతో TCP పనిచేస్తుందని మాత్రమే నిరూపిస్తుంది. ఇది UDP 500, UDP 4500 లేదా ప్రోటోకాల్ 50 గురించి ఏమీ చెప్పదు, ఈ అమలు ఆ మూడింటిపైనే ఆధారపడి ఉంది.

దశ 1: IKE కి ఏదో విధంగా సమాధానం రావాలి

మొదటి మార్పిడి UDP 500 పై సమాధానం ఇచ్చేవారి వద్దకు వెళ్తుంది. ఏ సమాధానం తిరిగి రాకపోతే, మిగతా ఏదీ ముఖ్యం కాదు: ముందుగా పంచుకున్న కీ, ప్రతిపాదన, ఆధారాలు అన్నీ చదవకుండానే ఉంటాయి. క్లయింట్ సమయ పరిమితి నుండి ఊహించకుండా అభ్యర్థన మరియు సమాధానాన్ని గమనించండి:

sudo tcpdump -n -i any 'udp port 500 or udp port 4500 or proto 50'
swanctl --list-sas

సమాధానం లేని అభ్యర్థన సాధారణంగా ఫైర్వాల్ లేదా పైనున్న క్యారియర్ ప్యాకెట్ను పారవేస్తున్నారని అర్థం, సర్వర్ దాన్ని తిరస్కరించిందని కాదు. ప్రతిపాదన లేదా సర్టిఫికెట్ సమస్యను పేర్కొనే నోటిఫికేషన్ పేలోడ్తో వచ్చిన సమాధానం అంటే ప్యాకెట్లు చేరాయి మరియు చర్చలు కంటెంట్ కారణంగా విఫలమయ్యాయి, ఇది పూర్తిగా వేరే మరమ్మత్తు.

రెండు వైపులా అనువాదం వెనుక ఉన్నప్పుడు, ప్రారంభించేవారు సమాధానం ఇచ్చేవారిని చేరుకోవాలి మాత్రమే, కాబట్టి చాలా క్లయింట్-వైపు అమలులు దశ 1 నుండి పనిచేస్తాయి. సర్వర్-వైపు హోస్టింగ్ అనేది ఇన్బౌండ్ సమస్య ప్రారంభమయ్యే చోటు, అందుకే ఈ రెండు పరిస్థితులను ఎప్పుడూ ఒకటిగా చర్చించకూడదు.

దశ 2: ఎన్క్యాప్సులేషన్ ఫైర్వాల్ చూసేదాన్ని మారుస్తుంది

ESP ఒక IP ప్రోటోకాల్, TCP లేదా UDP పోర్ట్ కాదు, మరియు సాధారణ పోర్ట్ చిరునామా అనువాదంలో తిరిగి రాయడానికి పోర్ట్ ఫీల్డ్ లేదు. అందుకే NAT traversal రక్షిత పేలోడ్ను UDP 4500 లోకి కదిలిస్తుంది: ఎన్క్యాప్సులేషన్ అనువదించే పరికరానికి అది అనువదించడం తెలిసినదాన్ని ఇస్తుంది. అలా జరిగిన తర్వాత, UDP 500 కోసం మాత్రమే రాసిన ఫైర్వాల్ నియమం చర్చలను అనుమతించి టన్నెల్ను పారవేస్తుంది, ఇది లాగ్ విజయవంతమైన దశ 1 మరియు ఎటువంటి ట్రాఫిక్ లేదని చూపే గందరగోళ ఫలితాన్ని ఇస్తుంది.

NAT గుర్తించిన తర్వాత IKE మార్పిడి కూడా UDP 4500కి మారవచ్చు, ఇది 500కి మాత్రమే అనుమతించినవారిని ఆశ్చర్యపరుస్తుంది. మార్గంలో రెండు పోర్టులను రెండు దిశల్లో అనుమతించండి, మరియు స్టేట్ఫుల్ ఫైర్వాల్ ట్రాఫిక్ కనిపించినంత కాలమే ప్రవాహాన్ని ఉంచుతుందని గుర్తుంచుకోండి.

ప్రోటోకాల్ 50 అనువాదం లేని మార్గాల్లో మరియు మధ్యవర్తి బాక్స్ దాన్ని అనుమతించడానికి కాన్ఫిగర్ చేయబడిన మార్గాల్లో ఇప్పటికీ ముఖ్యం. మీరు తొలగింపు ద్వారా నిర్ధారణ చేస్తుంటే, నియమాలను కుప్పగా జోడించడం బదులు ఊహను ఆపండి: 500, 4500, ESP అనుమతించండి, టన్నెల్ పైకి వస్తుందని నిర్ధారించి, అనవసరమని తేలినది తీసివేయండి. ఎవరూ వివరించలేని నియమం తదుపరి అంతరాయానికి కారణమైనప్పుడు ఎవరూ తీసివేయని నియమం. సంకోచాన్ని మార్పు రికార్డులో అది సరిచేసిన దశతో పాటు రాయండి, తదుపరి ఇంజనీర్ అదే బొటనవేలు నియమం నుండి కాదు, మీ సాక్ష్యం నుండి ప్రారంభించేలా.

దశ 3: మ్యాపింగ్ గడువు ముగుస్తుంది మరియు టన్నెల్ చనిపోతుంది

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

చనిపోయిన భాగస్వామి గుర్తింపు మరియు NAT keepalive ఇదే కోసం ఉన్నాయి, రెండు చివరలు వాటిని పంపడానికి సిద్ధంగా ఉండాలి. మీ సర్వర్ అనువాదం వెనుక ఉంటే, Windows వైపు అవసరం సర్వర్ తన స్వంత బయటకు వెళ్లే ప్యాకెట్లకు UDP ఎన్క్యాప్సులేషన్ ఊహించేలా చేసే డాక్యుమెంటెడ్ రిజిస్ట్రీ సెట్టింగ్; అది లేకుండా సమాధానం ఇచ్చేవారు అనువదించే పరికరం తిరిగి మ్యాప్ చేయలేని ESP పంపుతారు. ఇది సర్వర్ కాన్ఫిగరేషన్ సమస్య, క్లయింట్ది కాదు.

WAN చిరునామా మారితే మరో దిశ నుండి అదే ఫలితం: మ్యాపింగ్ కొత్త చిరునామా చుట్టూ తిరిగి నిర్మించబడుతుంది, పాత భద్రతా సంఘం ఇప్పుడు లేని జోడీని సూచిస్తుంది. తిరిగి కనెక్ట్ అయ్యే ప్రవర్తన క్లయింట్ అమలుకు చెందుతుంది, అందుకే “రౌటర్ రీబూట్ తర్వాత తిరిగి కనెక్ట్ అవ్వండి” ఒక క్లయింట్లో పనిచేస్తుంది, మరొకదానిలో చేతితో టోగుల్ అవసరం.

క్యారియర్-గ్రేడ్ NAT వెనుక హోస్టింగ్ వేరే సమస్య

మీరు ఇంట్లో L2TP/IPsec సర్వర్ను హోస్ట్ చేసి బయటి నుండి చేరుకోవాలంటే, అవసరం కోరని ఇన్బౌండ్ చేరుకోగల సామర్థ్యం, అది NAT traversal ఇచ్చేది కాదు. మీ రౌటర్ ముందు క్యారియర్-గ్రేడ్ NAT ఉంటే, పబ్లిక్ చిరునామా పంచుకోబడుతుంది మరియు మ్యాపింగ్ బయటకే ఉంటుంది కాబట్టి, మిమ్మల్ని చేరుకోగలిగేలా చేసే పోర్ట్ ఏదీ లేదు.

ఏ IPsec పాస్-త్రూ చెక్బాక్స్ దాన్ని మార్చదు, ఏ క్లయింట్ కాన్ఫిగరేషన్ దాన్ని భర్తీ చేయదు. మద్దతు ఉన్న సమాధానాలు నిజంగా చేరుకోగల చిరునామా, హోస్ట్ చేసిన ముగింపు బిందువు, లేదా ప్రతి భాగస్వామి బయటకు వెళ్లే కనెక్షన్ చేసే నిర్మాణం. UDP ఎన్క్యాప్సులేషన్ స్పెసిఫికేషన్ ఇప్పటికే ఉన్న ప్రవాహాలకు అనువాద సమస్యను పరిష్కరిస్తుంది; క్యారియర్ అందించని చోట అది ఇన్బౌండ్ మార్గాన్ని సృష్టించదు.

కాబట్టి ఊహించకుండా నెట్వర్క్లను పోల్చండి. అదే పరికరం మరియు ప్రొఫైల్ను మరో అనుమతించిన నెట్వర్క్కు తీసుకెళ్లి అక్కడ ఏ దశ విఫలమవుతుందో చూడండి. వేరే చోట పనిచేస్తే, తేడా మార్గంలో ఉంది, అది మొత్తం కాన్ఫిగరేషన్కు బదులు పైనున్న మూడు దశలకు అన్వేషణను తగ్గిస్తుంది.