స్థానిక యాప్, VPN నియమం: మీ FORWARD చైన్ ఎందుకు ఎప్పటికీ పనిచేయదు
మెషీన్లోని ప్రక్రియ OUTPUTని ఉపయోగిస్తుంది, FORWARD కాదు. సరైన namespaceలో hook ఎంచుకుని, ఆపై mark లేదా సాధారణ route సరిపోతుందా అని నిర్ణయించండి.
మీరు FORWARD చైన్లో VPN ట్రాఫిక్ కోసం నియమాన్ని జోడిస్తారు, అదే Linux మెషీన్ నుండి అభ్యర్థనను నడుపుతారు, కౌంటర్ సున్నా వద్దే ఉంటుంది. నియమం బహుశా సరైనదే. పాకెట్ ఆ మార్గాన్ని ఎప్పటికీ తీసుకోలేదు, ఎందుకంటే మెషీన్లోనే పుట్టిన అభ్యర్థనను అది ముందుకు పంపదు. సాకెట్ నుండి తీగ వరకు పాకెట్ జీవితాన్ని అనుసరించడం ఎందుకు అలా జరుగుతుందో, నియమం నిజంగా ఎక్కడ ఉండాలో వివరిస్తుంది.
పాకెట్ ఎక్కడ పుట్టిందో కనుగొనండి
Netfilter hook క్రమం మూడు సందర్భాలను వేరు చేస్తుంది, అందులో ఒకటి మాత్రమే FORWARD కలిగి ఉంటుంది:
| Origin | Path | Hook that sees it |
|---|---|---|
| Local process | OUTPUT then POSTROUTING | OUTPUT, POSTROUTING |
| Addressed to a local service | PREROUTING then INPUT | PREROUTING, INPUT |
| Received for another host | PREROUTING, FORWARD, POSTROUTING | FORWARD |
స్థానిక యాప్లికేషన్ OUTPUT మార్గంలో ప్రారంభమవుతుంది, ఎందుకంటే పాకెట్ ఇక్కడే పుడుతుందని, అది ఎప్పటికీ ముందుకు పంపడానికి అభ్యర్థి కాదని కర్నెల్ ఇప్పటికే నిర్ణయించింది. టన్నెల్ సృష్టించడం ఆ వర్గీకరణను మార్చదు; టన్నెల్ అనేది పాకెట్ బయటకు వెళ్లగల పరికరం, స్థానిక అవుట్పుట్ను ట్రాన్సిట్గా మార్చే దశ కాదు.
రెండు పాకెట్లు, ఒక కథ
టన్నెల్ లేచిన తర్వాత యాప్ లోపలి పాకెట్ మరియు ఎన్క్రిప్ట్ చేసిన బయటి పాకెట్ వేర్వేరు వస్తువులు. లోపలి పాకెట్ యాప్ ఎంచుకున్న గమ్యాన్ని, పేలోడ్ను మోసుకెళ్తుంది. బయటి పాకెట్ సైఫర్టెక్స్ట్ను సహచరుడి చిరునామా, పోర్టుకు తీసుకెళ్తుంది, భౌతిక ఇంటర్ఫేస్ను నిజంగా దాటేది అదే.
మీ విధానం వాటిలో ఒకదానికి సంబంధించింది, తప్పుదాన్ని ఎంచుకోవడం నియమం ఏమీ చేయనట్లు కనిపించడానికి సాధారణ కారణం. సహచరుడి బయటి చిరునామాతో సరిపోలే నియమం ప్రతి టన్నెల్ పాకెట్ను ఒకేలా చూస్తుంది, లోపలి యాప్ ఏమి చేసినా. లోపలి గమ్యంతో సరిపోలే నియమం మీకు ముఖ్యమైన ట్రాఫిక్ను చూస్తుంది, మీరు నియమాన్ని ఉంచిన hookకు ఆ పాకెట్ చేరితేనే అది పనిచేస్తుంది.
namespace సరిహద్దును కదిలిస్తాయి
కంటైనర్ సూత్రాన్ని మార్చకుండా దీన్ని కష్టతరం చేస్తుంది. యాప్ అభ్యర్థన కంటైనర్ నెట్వర్క్ namespace లోపలి స్థానిక అవుట్పుట్. హోస్ట్ ఆ ట్రాఫిక్ను వర్చువల్ Ethernet ఇంటర్ఫేస్లో స్వీకరించి ముందుకు పంపగలదు, కాబట్టి అభ్యర్థనను సృష్టించిన ప్రక్రియ హోస్ట్ OUTPUT చైన్ను ఎప్పుడూ తాకకపోయినా హోస్ట్లోని FORWARD నియమం అర్థవంతంగా ఉండవచ్చు.
hook ఎంచుకునే ముందు నియమాల సముదాయం, టన్నెల్ నిజంగా ఎక్కడ ఉన్నాయో నిర్ధారించండి. కంటైనర్ లోపల టన్నెల్, కంటైనర్ను దాని ద్వారా route చేసిన హోస్ట్లోని టన్నెల్, వేరే namespaceలోని టన్నెల్ — ఇవి మూడు వేర్వేరు టోపాలజీలు, మూడు వేర్వేరు నియమ స్థానాలు. పరికరాన్ని కలిగి ఉన్న namespace లోపల నియమాలను చదవండి, డిఫాల్ట్లో మాత్రమే కాదు.
mark అసలు అవసరమా అని అడగండి
ఒక గమ్య ప్రిఫిక్స్ను టన్నెల్ ద్వారా పంపడం లక్ష్యమైతే, ఆ ప్రిఫిక్స్కు ఒక route సరిపోవచ్చు. మొదట ప్రభావవంతమైన routeలను తనిఖీ చేయండి, సర్వర్ నెట్టిన ప్రతిదీ సహా: రీడైరెక్ట్ చేసిన డిఫాల్ట్ మీరు ఊహించిన సన్నని విధానం కంటే చాలా ఎక్కువ ట్రాఫిక్ను VPN ద్వారా పంపుతుంది, ఎంత mark చేసినా ఫలితం ఉద్దేశంతో సరిపోలదు.
route వ్యక్తపరచలేని దానిపై నిర్ణయం ఆధారపడినప్పుడు వర్గీకరణ అవసరం, ఉదాహరణకు మూలం, వినియోగదారు లేదా ప్రక్రియ. స్వీకరించిన ట్రాఫిక్కు PREROUTINGలో mark పనిచేస్తుంది. స్థానిక ట్రాఫిక్కు mark, mark పెట్టిన తర్వాత కొత్త route అన్వేషణను రేకెత్తించగల అవుట్పుట్ దశలో జరగాలి. nftablesలో అది అవుట్పుట్ hookలో route రకం చైన్; సాధారణ అవుట్పుట్ ఫిల్టర్ చైన్ విలువను పెట్టి routeను మార్చకుండా వదిలేస్తుంది.
iptablesలో సమానమైనది mangle OUTPUT అమరికలో ఉంటుంది, అదే షరతు వర్తిస్తుంది: mark ఉన్న తర్వాత route నిర్ణయాన్ని మళ్లీ చూడాలి. తర్వాత విధాన నియమం markను వినియోగించి ఉపయోగపడే route ఉన్న పట్టికను చూపాలి. conntrack mark పెట్టడం మూడవ, ప్రత్యేక ఆపరేషన్; అది ప్రవాహంపై విలువను నిల్వ చేస్తుంది, ఆ విలువను route చదవగలిగేలా ప్రస్తుత పాకెట్పై తానే పెట్టదు.
అన్వేషణ, కౌంటర్ను కలిసి ధృవీకరించండి
nft list ruleset
ip route get 198.51.100.25
ip route get 198.51.100.25 mark 0x1చిరునామా, mark ఉదాహరణలు, రెండు route ప్రశ్నలు వేర్వేరు ప్రశ్నలకు సమాధానం ఇస్తాయి. రెండవది పాకెట్పై ఆ mark ఉంటే కర్నెల్ ఏమి చేస్తుందని అడుగుతుంది; మీ నియమాల సముదాయం ఒకటి ఇస్తుందని అది చూపదు. దీన్ని ఊహా పరీక్షగా పరిగణించండి, విధానం పనిచేస్తుందనే రుజువుగా కాదు.
తర్వాత హానిలేని అభ్యర్థనను నడిపి ఒకేసారి రెండు విషయాలు చూడండి: మీరు ఎంచుకున్న hookలోని కౌంటర్, పాకెట్ నిజంగా తీసుకున్న నిర్గమనం. కౌంటర్ పెరిగి పాకెట్ వేరే చోటి నుండి బయటపడితే mark లేదా పట్టిక తప్పు. రెండూ పెరకపోతే పాకెట్ ఆ hookకు అసలు చేరదు, తదుపరి ప్రశ్న namespace లేదా మార్గం.
చివరగా, పరీక్షను యంత్రాంగం వ్యక్తపరచగలిగేదానికే పరిమితం చేయండి. ఒక చిరునామాకు ఒక route, చిరునామాలు మారే సేవకు శాశ్వత విధానం కాదు. మొదట పాకెట్ల పరిధిని నిర్ణయించి, మళ్లీ కనెక్ట్ అయిన తర్వాత కూడా route, mark రూపకల్పన ఆ పరిధిని నిలబెట్టగలదా అని తనిఖీ చేయండి.