Linux లో IPsec లేకుండా L2TP: xl2tpd, pppd మరియు NAT

సాదా L2TP అనేది కవరు లోపలి PPP, అంతకంటే ఏమీ లేదు. ఇది మీ ఫ్రేమ్‌లను మోసుకెళ్తుంది; వాటిని గుప్తీకరించదు మరియు ఆ చివర ఎవరు కూర్చున్నారో నిరూపించదు, అందుకే దాదాపు ప్రతి అమలులో దాని కింద IPsec పెడుతుంది. నగ్న సంస్కరణను నడపడానికి నిజాయితీ కారణాలు ఇప్పటికీ ఉన్నాయి: ప్రయోగశాల బెంచ్, స్థలాంతరణ దశ, లేదా ఇప్పటికే మరో రక్షిత మార్గం లోపల ఉన్న లింకు.

మీరు ముందుకు వెళితే, ఆ హెచ్చరికను డిజైన్ నోట్‌లో రాయండి మరియు అక్కడే ఉంచండి. తరువాత చెప్పేది Debian మరియు RHEL కుటుంబ హోస్ట్‌లపై నేను ఉపయోగించే కార్యాచరణ మార్గం: ఏ ఫైలు దేనికి బాధ్యత, క్లాసిక్ నిలిచిపోవడాన్ని నిరోధించే MTU, మరియు సొరంగాన్ని విలువైనదిగా చేసే ఫార్వార్డింగ్ నియమాలు.

మూడు ఫైళ్లు పనిని పంచుకుంటాయి

xl2tpd నియంత్రణ కనెక్షన్‌ను ముగించి ప్రతి సెషన్‌ను PPP డీమన్‌కు అప్పగిస్తుంది, కాబట్టి కాన్ఫిగరేషన్ ఒకదాని ఫైళ్లను మరొకటి ఎప్పుడూ చదవని రెండు ప్రోగ్రాముల మధ్య విభజించబడి ఉంటుంది. శ్రోత /etc/xl2tpd/xl2tpd.conf లో, [lns default] విభాగం లోపల నివసిస్తుంది; అది చిరునామా పూల్‌ను ip range తో, సర్వర్ వైపును local ip తో, PPP కి అప్పగింపును pppoptfile తో పేర్కొంటుంది. require authentication = yes ఆన్ చేయండి, length bit మరియు flow bit ఆన్‌లో ఉంచండి, హోస్ట్‌లో మరేదీ ఉపయోగించని పూల్‌ను ఎంచుకోండి.

PPP విధానం ఆ ఎంపిక పేర్కొనే ఫైల్‌ది, సాధారణంగా /etc/ppp/options.xl2tpd: auth, pap, chap మరియు mschap కోసం నిరాకరణలు, require-mschap-v2, 1460 యొక్క MTU మరియు MRU, మరియు లింకు పైకి వచ్చిన తర్వాత క్లయింట్ చేరుకోగల DNS చిరునామా. ఆధారాలు మళ్లీ మూడవ ఫైల్, /etc/ppp/chap-secrets, అక్కడ రెండవ ఫీల్డ్ LNS విభాగం పేరుతో సరిపోలాలి మరియు నాల్గవ ఫీల్డ్ పూల్ నుండి నిర్దిష్ట చిరునామాన్ని పిన్ చేయగలదు.

సొరంగం ఎందుకు కనెక్ట్ అయి తర్వాత నిలిచిపోతుంది

1500 బైట్ల Ethernet ఫ్రేమ్ తన సొంత హెడర్లపై బైట్లు ఖర్చు చేసే మార్గంలో ఇమడదు. బయటి IPv4 హెడర్ 20 తీసుకుంటుంది, UDP 8, మరియు L2TP హెడర్ సుమారు 12, ఇది PPP మరియు దాని పేలోడ్ కోసం 1460 వదిలిస్తుంది. PPP లో ఆ చిన్న సంఖ్యను ప్రకటించడమే పెద్ద ప్యాకెట్లు ముక్కలు కాకుండా లేదా మధ్యలో ఎక్కడో నిశ్శబ్దంగా పడిపోకుండా నిరోధిస్తుంది.

లక్షణం నిజమైన ట్రాఫిక్ వచ్చే వరకు ఆరోగ్యంగా కనిపించే సొరంగం: పింగ్‌లు మరియు నియంత్రణ సందేశాలు దాటుతాయి, ఫైల్ కాపీ నిలిచిపోతుంది, లాగ్‌లో ఏదీ దాన్ని వివరించదు. రెండు చివరలా MTU మరియు MRU ను కలిసి తగ్గించండి. క్లయింట్‌ను మాత్రమే సర్దుబాటు చేస్తే గట్టి నిలిచిపోవడం అప్పుడప్పుడు వచ్చే సమస్యగా మారుతుంది, దాన్ని నిర్ధారించడం మరింత కష్టం.

ఒక పోర్టు రెండు సంభాషణలను మోస్తుంది

UDP 1701 ప్రోటోకాల్ రెండు భాగాల కింద ఉంటుంది, మరియు ఆ ఒక్క వాస్తవం సెటప్‌లోని మరే భాగం కంటే ఎక్కువ firewall నియమాలను బద్దలు కొడుతుంది. మొదట నియంత్రణ-కనెక్షన్ ప్రారంభ అభ్యర్థన మరియు దాని సమాధానం వస్తాయి; తర్వాత వచ్చే సెషన్ అభ్యర్థన మరియు నిర్ధారణ గుర్తింపు జంట కంటే ఎక్కువ ఏమీ స్థాపించవు. తర్వాత PPP బాధ్యత తీసుకుంటుంది: లింకు నియంత్రణ, తర్వాత ప్రామాణీకరణ, తర్వాత చిరునామాలను ఒప్పుకోవడానికి IP నియంత్రణ ప్రోటోకాల్. ప్రతి దశకు లాగ్‌లో దాని సొంత పదజాలం ఉంది, ఏదీ తనను L2TP వైఫల్యంగా ప్రకటించుకోదు.

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

సొరంగాన్ని ఉపయోగకరంగా చేయడం: ఫార్వార్డింగ్ మరియు NAT

సెషన్ దానంతట అదే సర్వర్‌ను మాత్రమే చేరుతుంది. క్లయింట్ ఇంటర్నెట్ యాక్సెస్‌కు ఫార్వార్డింగ్, పై లింకుపై పూల్ కోసం NAT నియమం, మరియు లింకు పైకి వచ్చిన తర్వాత క్లయింట్ నిజంగా అడగగల DNS అవసరం. పూల్ LAN పరిధి వెలుపల ఉండాలి, లేకపోతే క్లయింట్లకు పంపిన సమాధానాలు సొరంగంలోకి తిరిగి నెట్టడానికి బదులు స్థానికంగా పంపబడతాయి.

సర్వర్‌పై sysctl -w net.ipv4.ip_forward=1 తో ఫార్వార్డింగ్ ఆన్ చేయండి, iptables -t nat -A POSTROUTING -s 10.44.0.0/24 -o eth0 -j MASQUERADE తో పూల్‌ను అనువదించండి, ఆపై -i ppp0 -o eth0 కోసం FORWARD నియమంతో బయటకు వెళ్లే సొరంగ ట్రాఫిక్ మరియు అద్దపు నియమంతో పాటు -m state --state RELATED,ESTABLISHED తో తిరిగి వచ్చే ట్రాఫిక్‌ను అంగీకరించండి. ఆ నియమాలను పునఃప్రారంభాల మధ్య నిలిచి ఉండేలా చేయండి, ఎందుకంటే అవి లేకుండా తిరిగి వచ్చే సర్వర్ పాడైన L2TP కాన్ఫిగరేషన్‌లాగే కనిపిస్తుంది.

సర్వర్ సొంత LAN ను చేరుకోవడం మరో పని: LAN రౌటర్‌పై పూల్ కోసం తిరోగమన మార్గాన్ని జోడించండి, లేదా సర్వర్‌పై proxy ARP ఉపయోగించండి. LAN లోపల ఏదో క్లయింట్లను నేరుగా సంబోధించాల్సి వచ్చినప్పుడు వారిని NAT వెనుక దాచడం తర్వాత రెండవ డీబగ్గింగ్ సెషన్‌ను షెడ్యూల్ చేయడమే.

నగ్న స్టాక్ ఏమి చేయదు, మరియు ఎలా ధృవీకరించాలి

ఈ స్టాక్‌లో ఏ భాగం PPP ఫ్రేమ్‌లను గుప్తీకరించదు, దానిలో ఏదీ మీరు నిజంగా ఎంచుకున్న సర్వర్‌గా దూర చివరను ప్రామాణీకరించదు. MS-CHAPv2 కేవలం చూస్తున్న శ్రోత నుండి ఆధారాల మార్పిడిని కాపాడుతుంది, అయినా మార్గంలో ఉన్న దాడిదారుడు ఇప్పటికీ సెషన్‌లో జోక్యం చేసుకోగలడు. Windows స్థానిక క్లయింట్ L2TP ను IPsec తో మాత్రమే అందిస్తుంది, కాబట్టి Linux, రౌటర్ ఫర్మ్‌వేర్ మరియు మూడవ పక్ష క్లయింట్లను మీ భాగస్వాములుగా లెక్కించండి. నగ్న కాన్ఫిగరేషన్‌ను నిర్ధారణ మెట్టుగా పరిగణించండి, ఎప్పుడూ ఆగే స్థలంగా కాదు.

నిర్దిష్ట క్రమంలో ధృవీకరించండి: xl2tpd -D ను ముందు భాగంలో అమలు చేయండి, PPP దశ కోసం జర్నల్‌ను గమనించండి, రెండు చివరలా ip addr నుండి కేటాయించిన చిరునామాను చదవండి, ఆపై సెషన్ పైకి వచ్చిన తర్వాత డేటా ప్రవహిస్తుందని నిర్ధారించడానికి UDP 1701 ను క్యాప్చర్ చేయండి. నాలుగూ సరిపోలినా ట్రాఫిక్ ఇంకా విఫలమైతే, తప్పు రూటింగ్, NAT లేదా MTU లో ఉంది, L2TP లో కాదు.