వేరైన నిష్క్రమణ: usb0 పై VPN పూల్, eth0 పై గేట్‌వే ట్రాఫిక్

క్లయింట్లు కనెక్ట్ అయి ప్రామాణీకరణ చేసుకుంటాయి, తర్వాత వాటి ట్రాఫిక్ తప్పు పై లింక్ ద్వారా బయటకు వెళ్తుంది, ఎందుకంటే యంత్రంలోని ఏకైక డిఫాల్ట్ మార్గం గేట్‌వేదే. ఆ డిఫాల్ట్‌ను మార్చడం యంత్రం సొంత నవీకరణలను, నిర్వహణ ప్రవేశాన్ని విచ్ఛిన్నం చేస్తుంది, కాబట్టి ఎంపిక «మొత్తం ట్రాఫిక్» కంటే సన్నగా ఉండాలి. పనిచేసే రూపం క్లయింట్ పూల్ లోపలి మూల చిరునామా ఆధారంగా ఉన్న విధాన నియమం, ఇది ప్రత్యామ్నాయ WAN కలిగిన రెండవ రూటింగ్ పట్టిక వైపు సూచిస్తుంది. అక్కడి నుంచి చెక్‌లిస్ట్ నియమం గురించి కాదు, పూర్ణత్వం మరియు వైఫల్య సమయ ప్రవర్తన గురించి.

మూల చిరునామా రూటింగ్ నిర్ణయం వరకు నిలిచి ఉంటుందని నిర్ధారించండి

మూల పరిధికి సరిపోయే విధాన నియమం, శోధన సమయంలో ప్యాకెట్ ఆ మూలాన్ని ఇంకా మోసుకెళ్తున్నప్పుడే పనిచేస్తుంది. ఫార్వర్డ్ చేసిన క్లయింట్ ట్రాఫిక్ అలా చేస్తుంది, రూటింగ్‌కు ముందు పైన ఏదీ దాన్ని తిరిగి రాయకపోతే. గేట్‌వే తానే ఉత్పత్తి చేసే ట్రాఫిక్ అలా చేయదు, అందుకే గేట్‌వే సొంత డిఫాల్ట్ తన స్థానంలో ఉండగలదు.

ఇక్కడే స్థానిక పరీక్షలు తప్పుదోవ పట్టిస్తాయి. గేట్‌వేపై నడిపిన curl అనేది గేట్‌వే చిరునామాతో స్థానికంగా సృష్టించిన ప్రవాహం, కాబట్టి అది ప్రధాన పట్టికను తీసుకుంటుంది మరియు క్లయింట్ మార్గం గురించి ఏమీ నిరూపించదు. కనెక్ట్ అయిన క్లయింట్ నుండి పరీక్షించండి, లేదా పూల్‌కు నిజంగా చెందిన మూలంతో ట్రాఫిక్ సృష్టించండి.

నిజమైన విలువలను రాయడంతో ప్రారంభించండి: పూల్ ప్రిఫిక్స్, దాన్ని మోసుకెళ్లే టన్నెల్ ఇంటర్‌ఫేస్, రెండవ WAN చిరునామా మరియు తదుపరి హాప్, మరియు మీరు ఉపయోగించాలనుకునే పట్టిక సంఖ్య. కొత్త నియమాలు జోడించే ముందు ఏదైనా మునుపటి ప్రయత్నం యొక్క పాత నియమాలను శుభ్రం చేయండి, ఎందుకంటే వేర్వేరు ప్రాధాన్యతలపై నకిలీ నియమాలు యాదృచ్ఛికంగా కనిపించే వైఫల్యాలను సృష్టిస్తాయి.

పూర్తయిన ఎంపిక చేసిన పట్టికను నిర్మించండి

పట్టిక అనేది స్నేహితుడితో కూడిన డిఫాల్ట్ మార్గం కాదు. ప్రతి శోధన దాని లోపలే పరిష్కారం కావడానికి సరిపడా మార్గాలు కావాలి, తదుపరి హాప్ చేరుకోగలిగేలా WAN ఉపజాలం యొక్క అనుసంధాన మార్గం కూడా. tun1 పై 10.77.0.0/24 పూల్, తదుపరి హాప్ 203.0.113.1 కలిగిన WAN చిరునామా 203.0.113.20/24, మరియు పట్టిక 600 కోసం:

ip -4 route replace 203.0.113.0/24 dev usb0 src 203.0.113.20 table 600
ip -4 route replace 10.77.0.0/24 dev tun1 table 600
ip -4 route replace default via 203.0.113.1 dev usb0 table 600
ip -4 rule add priority 1500 from 10.77.0.0/24 lookup 600

నియమం ఇప్పటికే ఉన్న ఏదైనా అన్నింటినీ పట్టుకునే నియమం కంటే తక్కువ ప్రాధాన్యతలో ఉంటుంది, కాబట్టి సరిపోయే క్లయింట్లు మొదట పట్టిక 600ను చేరుకుంటాయి, మిగతావన్నీ ప్రధాన పట్టికలోకి పడతాయి. ip-rule సూచన క్రమబద్ధ శోధన నమూనాను, ఎంపికదారు వాక్యనిర్మాణాన్ని పూర్తిగా వివరిస్తుంది.

తర్వాత పట్టికలో లేని దాని గురించి ఆలోచించండి. ప్రధానంలో మాత్రమే మార్గం ఉన్న గమ్యం, ఉదాహరణకు eth0 ద్వారా చేరుకోగల నిర్వహణ ఉపజాలం, పట్టిక 600లో కనబడదు, అక్కడ డిఫాల్ట్ ఉన్నప్పుడు ప్రధానానికి తిరిగి రాదు. ఆ మార్గాలు ముఖ్యమైతే వాటిని స్పష్టంగా ఎంపిక చేసిన పట్టికలో జోడించండి, ఇది VPN నిష్క్రమణ పట్టికకు సాధారణంగా సరైన సమాధానం.

శ్రోత సొంత ట్రాఫిక్‌ను విధానం బయట ఉంచండి

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

తిరోమార్గ వడపోత కూడా అదే కారణంతో చూడదగినది. క్లయింట్లకు సమాధానాలు usb0 ద్వారా వెళ్తుండగా అభ్యర్థన వేరే లింక్ ద్వారా వచ్చినప్పుడు, కఠినమైన rp_filter అమరిక రూటింగ్ విధానం చెల్లుబాటు అని భావించే ప్యాకెట్లను పడవేయగలదు. నియమం విఫలమైందని నిర్ణయించే ముందు రెండు ఇంటర్‌ఫేస్‌లపై అమలులో ఉన్న sysctl విలువలను తనిఖీ చేయండి.

యంత్రంలోని మిగతా ప్రతిదానితో పోలిస్తే క్రమమూ ముఖ్యం. Docker వంతెనలు, రెండవ VPN మరియు ప్రొవైడర్ ఇమేజ్ నుండి ముందే ఉన్న ఏవైనా నియమాలు అన్నీ ప్రాధాన్యతలను జోడిస్తాయి, కాబట్టి ప్రాధాన్యత 100 ఒంటరిగా ఉందని భావించకుండా పూర్తి నియమ జాబితాను చదవండి.

ఫార్వర్డింగ్ మరియు అనువాదాన్ని మార్గంతో సరిపోల్చండి

రూటింగ్ పై లింక్‌ను ఎంచుకుంటుంది; అది ఫార్వర్డ్ చేయడానికి అనుమతి ఇవ్వదు. కెర్నల్‌లో IPv4 ఫార్వర్డింగ్ ప్రారంభంలో ఉండాలి, ఫైర్‌వాల్ క్లయింట్ నుండి WAN దిశను, తిరిగి వచ్చే ట్రాఫిక్‌ను అంగీకరించాలి. ప్రవాహాన్ని పడవేసే FORWARD చైన్‌తో కూడిన సరైన పట్టిక తప్పిపోయిన మార్గం లాంటి లక్షణాన్నే ఇస్తుంది, అందుకే రెండూ ఒకే దశలో తనిఖీ చేయబడతాయి.

రెండవ WAN ప్రైవేట్ పూల్‌ను మీ వైపు తిరిగి రూట్ చేయకపోతే, ఆ నిష్క్రమణపై మూలాన్ని అనువాదం చేయండి. చలన చిరునామా ఉన్న ఇంటర్‌ఫేస్‌కు పూల్ మరియు ఇంటర్‌ఫేస్‌కు పరిమితమైన సన్నని masquerade నియమం సాధారణ ఎంపిక:

iptables -t nat -A POSTROUTING -s 10.77.0.0/24 -o usb0 -j MASQUERADE

ఇక్కడ లక్ష్యం కంటే పరిధి ముఖ్యం. ఏదైనా బయటకు వెళ్లే ఇంటర్‌ఫేస్‌తో సరిపోయే masquerade నియమం eth0 ద్వారా సరిగ్గా వెళ్లే ట్రాఫిక్‌ను కూడా తిరిగి రాస్తుంది, అది రూటింగ్ తప్పులను సరిచేయడం బదులు దాచుతుంది. అనువాదం రూటింగ్ నిర్ణయం తర్వాత నడుస్తుంది, కాబట్టి తప్పు పై లింక్‌కు పంపిన ప్యాకెట్‌ను అది ఎప్పటికీ సరిచేయలేదు.

మార్గాలు భిన్నమైనప్పుడు టన్నెల్ ఓవర్‌హెడ్ కూడా శ్రద్ధ కోరుతుంది. క్లయింట్లు పెద్ద TCP MSS ను అంగీకరించి, ప్రత్యామ్నాయ WAN తక్కువ MTU లేదా లోపల టన్నెల్ కలిగి ఉంటే, పెద్ద విభాగాలు ఆగిపోతాయి చిన్నవి పనిచేస్తాయి. ఫార్వర్డింగ్ మార్గంలో MSS ను బిగించడం దాన్ని అప్పుడప్పుడు ఆగిపోవడం బదులు ముందుగా అంచనా వేయగల ప్రవర్తనగా మారుస్తుంది.

usb0 మాయమైనప్పుడు ఏమి జరుగుతుందో నిర్ణయించండి

ఖాళీ పట్టిక వైఫల్యంలో మూసుకుపోయే స్థితి కాదు. సరిపోయే మార్గం మాయమైతే, శోధన తదుపరి నియమం వైపు కొనసాగుతుంది, ప్రధాన పట్టికను చేరుకుని eth0 డిఫాల్ట్‌ను తీసుకుంటుంది. రెండవ WAN ద్వారా వెళ్లాల్సిన ట్రాఫిక్ నిశ్శబ్దంగా మొదటి దాని ద్వారా వెళ్తుంది, విధాన రూటింగ్ అమరికలో ఇది సాధారణంగా మీరు తక్కువగా కోరుకునే ఫలితం.

ఆ వెనక్కి పడటం ఆమోదయోగ్యం కాని చోట, పట్టిక 600లో స్పష్టమైన టెర్మినల్ మార్గాన్ని జోడించండి, ఉదాహరణకు blackhole డిఫాల్ట్, లేదా ఇంటర్‌ఫేస్ ఆఫ్‌లో ఉన్నప్పుడు ఫైర్‌వాల్‌లో పూల్‌ను పడవేయండి. రెండింటిలో ఏదైనా మీరు రాయగల నిర్ణయం; మౌనం కాదు.

నిలకడ చివరి అంశం. రెండు లింకుల యజమాని ఎవరైనా, అది నెట్‌వర్క్ మేనేజర్ అయినా, పంపే స్క్రిప్ట్ అయినా, కనెక్షన్ జీవిత చక్రం అయినా, ప్రతి తిరిగి కనెక్షన్‌లో నకళ్లు జోడించకుండా మార్గాలను, నియమాన్ని తిరిగి సృష్టించాలి. నిజమైన క్లయింట్ నుండి అభ్యర్థనతో, గేట్‌వే నుండి వేరే అభ్యర్థనతో ధృవీకరించండి, రెండింటిలో గమనించిన నిష్క్రమణను నిర్ధారించండి, తర్వాత రెండవ WAN ను లాగి మీరు రూపకల్పన చేసిన రెండు ఫలితాలలో ఏది నిజంగా జరుగుతుందో చూడండి. IPv6 కు దాని సొంత పట్టిక, నియమం, అనువాదం కావాలి; పైన ఉన్న IPv4 నియమం దాని గురించి ఏమీ చెప్పదు.