రెండు VPN పూల్స్ కోసం మూల రూటింగ్: మీ నియమం ఏమి జారిపోతుంది
from రూప నియమం SNAT తిరిగి రాయక ముందే క్లయింట్ చిరునామాతో సరిపోలుతుంది, గేట్‌వే నుండి చేసే పరీక్ష రెండింటిలో దేనితోనూ సరిపోలదు. ప్రతి పూల్‌కు లుకప్ అమలు చేసి బదులుగా ప్రాధాన్యతలు చదవండి.
రెండు క్లయింట్ పూల్స్, ఒక గేట్‌వే మరియు ప్రణాళిక సులభంగా కనిపిస్తుంది: ఒక నియమం మొదటి పూల్‌ను వేగవంతమైన అప్‌లింక్ ద్వారా పంపుతుంది, మరొకటి రెండవ పూల్‌ను భాగస్వామి సొరంగం ద్వారా పంపుతుంది. తరువాత నియమాలు స్థానంలో ఉన్నాయి మరియు రెండవ పూల్ ఇప్పటికీ డిఫాల్ట్ మార్గం ద్వారానే బయటకు వెళ్తుంది. నియమం విరగలేదు. లుకప్ సమయంలో రచయిత ఆశించినది ప్యాకెట్ మూలం కాదు, ఎందుకంటే అనువాదం మరియు లుకప్ ఒకే ప్యాకెట్ ప్రయాణంలో వేర్వేరు బిందువుల్లో జరుగుతాయి, మరియు క్రమం చాలామంది గీసే మానసిక చిత్రానికి వ్యతిరేకం.
మూలం తిరిగి రాయబడక ముందే లుకప్ జరుగుతుంది
VPN క్లయింట్ నుండి పంపబడే ప్యాకెట్ కోసం కెర్నల్ ఒక నిర్దిష్ట క్రమాన్ని అమలు చేస్తుంది. అది సొరంగ ఇంటర్‌ఫేస్‌కు చేరుతుంది, conntrack మరియు DNAT ఉన్న prerouting గుండా వెళ్తుంది, తరువాత రూటింగ్ నిర్ణయం తీసుకోబడుతుంది, తరువాత ఫార్వార్డింగ్, తరువాత SNAT చివరగా వర్తించే postrouting. from రూప నియమం ఆ రూటింగ్ నిర్ణయం సమయంలో పరిశీలించబడుతుంది, అంటే అది క్లయింట్ అసలు చిరునామాను చూస్తుంది, అనువదించినది కాదు.
కాబట్టి masquerade నియమాన్ని జోడించడం బయటకు వెళ్లే ప్రవాహానికి ఏ విధానం సరిపోతుందో మార్చదు. మారేది దూరపు చివర చూసేది, అందువల్ల ఏ తిరిగి వెళ్లే మార్గం ఉందో. ఇవి రెండు వేర్వేరు పరిణామాలు, మార్పు సమీక్షలు వాటిని నిరంతరం కలిపేస్తాయి. వాటిని వేరు చేయండి, డిజైన్ సాధారణంగా ఒక నిమిషంలో స్పష్టమవుతుంది.
సమాధానం దిశలోనే అనువదించిన చిరునామా నియమాల్లో కనిపిస్తుంది. గేట్‌వేకు తిరిగి వచ్చే ప్యాకెట్ అనువదించిన చిరునామాకు చిరునామా చేయబడుతుంది, గమ్యం లేదా అది ప్రవేశించిన ఇంటర్‌ఫేస్ ఆధారంగా విధాన నియమాలు ఉంటే, మీరు సరిపోల్చే విలువ అదే. ఒకే కనెక్షన్, ప్రతి దిశలో వేర్వేరు సత్య మూలం.
| Stage | Source the kernel sees | What it means for your rule |
|---|---|---|
| Prerouting | Client address, 172.31.7.42 | Where marks and DNAT are applied |
| Routing decision | Still 172.31.7.42 | This is where from rules match |
| Postrouting | Becomes 198.51.100.9 | What the far end and its return route see |
కాబట్టి వేర్వేరు మూలాలున్న రెండు పూల్స్‌కు నిజంగా వేర్వేరు పట్టికలు అవసరం, డిజైన్ సరైనది. పై పట్టిక తిరస్కరించేది దూర సైట్ ఏమి పొందిందో చూసి నియమాన్ని ఊహించడం.
గేట్‌వే నుండి చేసే పరీక్ష పూల్ పరీక్ష కాదు
గేట్‌వే తానే ఉత్పత్తి చేసే ట్రాఫిక్ ఎప్పుడూ prerouting గుండా వెళ్లదు, ఎందుకంటే అది ఏ ఇంటర్‌ఫేస్‌పైకి రాలేదు. అది అవుట్‌పుట్ మార్గంలో రూట్ చేయబడుతుంది, మూలంగా గేట్‌వే స్వంత చిరునామా, క్లయింట్ పరిధిపై ఆధారపడిన from నియమం సరిపోలదు. ఈ రంగంలో ప్రతి టికెట్ బాక్స్ నుండి పనిచేస్తుంది కానీ క్లయింట్ నుండి కాదు అని చెప్పేది ఆ వాస్తవం పునరుక్తి.
క్లయింట్‌ను అంచనా వేయడం బదులు అనుకరించండి. రూటింగ్ లుకప్‌ను నేరుగా అడగవచ్చు, మూలం మరియు ప్రవేశ ఇంటర్‌ఫేస్ ఇచ్చి:
ip route get 198.51.100.9 from 172.31.7.42 iif tun0
ip route get 198.51.100.9 from 172.31.8.42 iif tun0
ip route show table 201ప్రతి పూల్‌కు ఒకసారి అమలు చేయండి. రెండు ఆదేశాలు ఒకే ఇంటర్‌ఫేస్ ఇస్తే, నియమాలు పూల్స్‌ను వేరు చేయడం లేదు, కారణం తప్పిపోయిన నియమం లేదా రెండింటికీ సరిపోలే అధిక ప్రాధాన్యత నియమం. వేర్వేరు ఇంటర్‌ఫేస్‌లు ఇచ్చినా క్లయింట్ విఫలమైతే, లోపం లుకప్ తర్వాత ఉంది, నియమాలు చూడటం ఆపవచ్చు.
ప్రాధాన్యత, ఫైల్‌లో స్థానం కాదు
నియమాలు ప్రాధాన్యత ఆరోహణ క్రమంలో మూల్యాంకనం చేయబడతాయి, ముఖ్యమైనది సంఖ్య, మీరు టైప్ చేసిన క్రమం కాదు. local పట్టిక ప్రాధాన్యత 0 వద్ద, main పట్టిక 32766 వద్ద మరియు డిఫాల్ట్ నియమం 32767 వద్ద ఉంది, అందువల్ల డిఫాల్ట్ ప్రాధాన్యతతో జోడించిన నియమం జాబితా చివరకు దగ్గరగా పడి దాదాపు అన్నింటికీ ఓడిపోతుంది.
ip rule show
ip rule add from 172.31.8.0/24 lookup 201 priority 1000
ip -4 route show table 201స్పష్టమైన ప్రాధాన్యత ఉద్దేశించిన క్రమాన్ని ఫైల్‌లో మరియు సమీక్షలో కనిపించేలా చేస్తుంది. ఇది తర్వాతి జోడింపు ఉన్న నియమాన్ని నిశ్శబ్దంగా దాటకుండా కూడా నిరోధిస్తుంది, ఇది సంబంధం లేని మార్పు తర్వాత పనిచేస్తున్న విధానం ఆగిపోవడానికి సాధారణ కారణం.
అసంపూర్ణ పట్టిక వైపు చూపే సరిపోలే నియమం మరో ఉచ్చు. పట్టిక 201లో డిఫాల్ట్ మార్గం ఉంది కానీ గమ్యానికి మార్గం లేకపోతే, ప్యాకెట్ విస్మరించబడుతుంది లేదా తప్పు స్థలానికి పంపబడుతుంది, నియమం విడిగా చూస్తే పూర్తిగా సరైనదిగా కనిపిస్తుంది. నియమం మాత్రమే కాదు, పట్టిక చదవండి. నియమం ఒక సూచిక, ఖాళీ పట్టిక ఏమీ లేని వైపు సూచిక.
తిరిగి వెళ్లే మార్గం ఇంకా ఉండాలి
మూల విధానం ఒక నిష్క్రమణను ఎంచుకుంటుంది. అది తిరిగి వెళ్లే మార్గాన్ని సృష్టించదు. రెండవ పూల్ భాగస్వామి సొరంగం ద్వారా బయటకు వెళ్తే, భాగస్వామి 172.31.8.0/24కు ఎలా చేరుకోవాలో తెలుసుకోవాలి, గేట్‌వేకు తిరిగి వెళ్లే మార్గం ద్వారా లేదా ఇప్పటికే తెలిసిన అనువదించిన చిరునామాలు పొంది.
వాటి మధ్య ఎంపిక కనిపించే పరిణామాలున్న డిజైన్ నిర్ణయం. క్లయింట్ పరిధిని తిరిగి రూట్ చేయడం భాగస్వామి వద్ద ప్రతి క్లయింట్ గుర్తింపును నిలుపుతుంది మరియు మీ ప్రిఫిక్స్‌ను అంగీకరించమని కోరుతుంది. అనువాదం పూల్‌ను ఒక చిరునామా వెనుక దాచుతుంది మరియు భాగస్వామి ఆ చిరునామానే అంగీకరించమని కోరుతుంది, ఎవరు కనెక్ట్ అయ్యారనే దానిపై మీ మరియు అతని లాగ్‌లు ఇకపై ఏకీభవించని ధరకు.
మీరు ఏది ఎంచుకున్నా, దాన్ని పూల్ నిర్వచనం పక్కన రాయండి. ఒకరి జ్ఞాపకంలో మాత్రమే ఉన్న తిరిగి వెళ్లే మార్గం, భాగస్వామి ఫైర్‌వాల్ మార్చే వరకు నిలిచి, తర్వాత మళ్లీ నిర్మించడానికి ఒక రోజు తీసుకునే విషయం.
విధానంలో గేట్‌వే స్వంత సొరంగాన్ని పట్టుకోవద్దు
క్లయింట్ల కోసం మీరు రాసే నియమాలు గేట్‌వే ఉత్పత్తి చేసే ట్రాఫిక్‌కూ వర్తిస్తాయి, మీరు దాన్ని మినహాయించకపోతే. మార్క్ లేదా అవుట్‌పుట్ ఇంటర్‌ఫేస్ ఆధారంగా ఉన్న విశాల నియమం గేట్‌వే తన భాగస్వామితో ఉన్న సొంత కనెక్షన్‌ను పట్టుకోవచ్చు, అప్పుడు విధానాన్ని మోసే సొరంగం విధానం ద్వారా రూట్ చేయబడుతుంది. ఇది సేవా ప్రదాత లోపంలా కనిపించే లూప్ లేదా అంతరాయాన్ని కలిగిస్తుంది.
ప్రతి నియమాన్ని డిజైన్ అనుమతించినంత కుదించండి: మూల ప్రిఫిక్స్, ప్రవేశ ఇంటర్‌ఫేస్ మరియు మద్దతు ఉన్న చోట క్లయింట్ ప్యాకెట్లు మాత్రమే మోసే మార్క్. తర్వాత ప్రతి నియమ మార్పు తర్వాత గేట్‌వే సొంత కనెక్టివిటీని పరీక్షించండి, ఎందుకంటే లోపం స్వయం-సూచితం మరియు క్లయింట్ పరీక్షలో కనిపించదు.
ip-rule మాన్యువల్ పేజీ ఎంపికదారు మరియు ప్రాధాన్యత అర్థాన్ని నమోదు చేస్తుంది. దాన్ని ప్రతి పూల్ లుకప్ పరీక్షతో కలపండి, డిజైన్ పరిశీలించదగినదవుతుంది, ఇది ఒక సంవత్సరం నిలిచే విధాన రూటింగ్ మరియు అందరూ తాకడానికి భయపడే దాని మధ్య వ్యత్యాసం.