ప్యాకెట్లు OpenVPN మార్గాన్ని అనుసరించినా IPsec విధానం పట్టుకోవచ్చు, ఈ కలయిక సరైన కోణం తప్ప ప్రతి కోణం నుంచి రూటింగ్ బగ్గా కనిపిస్తుంది. Linux ఒక మార్గాన్ని పరిష్కరించి తర్వాత ప్రత్యేక భద్రతా విధాన డేటాబేస్ను సంప్రదిస్తుంది, కాబట్టి మరింత నిర్దిష్ట గమ్య మార్గం సరిపోలే XFRM విధానాన్ని తొలగించదు. కనిపించే లక్షణం హోస్ట్ను విడిచి ఎప్పటికీ చేరని ట్రాఫిక్, అయితే రెండు సొరంగాలు తాము ఆరోగ్యంగా ఉన్నట్టు ప్రకటించుకుంటాయి. మూడు ఎంపికలు దీన్ని పరిష్కరిస్తాయి, ఏది ఎంచుకోవాలో ఆ రెండు మార్గాల్లో ఏది ఆ ప్రిఫిక్స్ను మోయాలో దానిపై ఆధారపడి ఉంటుంది.

రెండు నిర్ణయాలు, ఒకటి కాదు

మార్గ ఎంపిక ఒక సన్నని ప్రశ్నకు సమాధానం ఇస్తుంది: ఏ తదుపరి హాప్ మరియు మూల చిరునామా ఈ ప్యాకెట్ను మోయాలి. భద్రతా విధాన డేటాబేస్ మరొకదానికి సమాధానం ఇస్తుంది: ఈ ప్యాకెట్కు IPsec రక్షణ అవసరమా, ఏ ఎంపికకారుల కింద. రెండూ ఒకే ప్యాకెట్ కోసం నడుస్తాయి, మరియు మొదటిది నెరవేర్చడం రెండోది గురించి ఏమీ చెప్పదు. అందుకే మెట్రిక్ మార్చడం లేదా స్థిర మార్గం జోడించడం లక్షణాన్ని తాకకుండా వదిలేయగలదు.

వెడల్పాటి IPsec ఎంపికకారుడే సాధారణ కారణం. 172.16.0.0/12ని రక్షించే విధానం 172.20.8.0/24నూ ఆవరిస్తుంది, అక్కడికి నిర్వాహకుడు OpenVPN సొరంగం ద్వారా చేరుకోవాలని ఉద్దేశించి ఉండవచ్చు. ఉద్దేశం రూటింగ్ పట్టికలో మాత్రమే ఉంది, విధాన డేటాబేస్ దాని గురించి ఎప్పుడూ తెలుసుకోలేదు.

దీన్ని రెండు మెట్రిక్ల పోటీగా కాక, కాన్ఫిగర్ చేసిన రెండు రక్షణ మార్గాల మధ్య ఘర్షణగా చూడండి. సవరణ తప్పు పరిధితో కాన్ఫిగర్ చేయబడిన భాగానికే చెందుతుంది.

కెర్నల్ నిజంగా ఎంచుకునే మార్గాన్ని చదవండి

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

ip rule show
ip route show table all
ip route get 172.20.8.20 from 10.44.7.15

చివరి ఆదేశమే ముఖ్యం, ఎందుకంటే అది ఎంచుకున్న మార్గాన్ని కెర్నల్ ఉపయోగించే మూల చిరునామాతో పాటు ముద్రిస్తుంది. ఆ అవుట్పుట్ను IPsec విధానం సరిపోలే ఎంపికకారుడితో పోల్చండి. మార్గం OpenVPN ఇంటర్ఫేస్ వైపు చూపుతూ విధానం ఇంకా అదే జంటతో సరిపోలితే, మీరు ఊహించకుండానే ఘర్షణను తిరిగి సృష్టించారు.

టికెట్ చేరే ముందు డంప్లను సంబంధం లేని చిరునామాల నుంచి విముక్తం చేయండి. ఉత్పత్తి హోస్ట్ రూటింగ్ పట్టిక అంతర్గత టోపాలజీని మోస్తుంది, ప్రశ్నకు సమాధానం ఇచ్చే పంక్తులు మాత్రమే అతికించదగినవి.

వర్తించే విధానాన్ని కూడా చదవండి

విధాన జాబితా దిశ, ఎంపికకారులను మరియు సరిపోలే ప్యాకెట్కు ఏమి జరుగుతుందో నిర్ణయించే టెంప్లేట్ను చూపుతుంది. మొదట బయటకు వెళ్లే దిశను, తర్వాత తిరిగి వచ్చే ట్రాఫిక్ కోసం లోపలికి వచ్చే వైపును చదవండి, ఎందుకంటే ఒక-దిశ మినహాయింపు ప్రారంభమై ఎప్పటికీ పూర్తికాని కనెక్షన్ను సృష్టిస్తుంది.

ip -s xfrm policy
swanctl --list-sas

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

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

రెండు మార్గాలు చట్టబద్ధమైనప్పుడు మూడు ఎంపికలు

వెడల్పాటి ప్రిఫిక్స్ అవసరం కాకుండా సౌలభ్యం అయినప్పుడు IPsec ఎంపికకారుడిని సన్నగా చేయడం అత్యంత శుభ్రమైన ఎంపిక. నిజంగా IPsec వెనుక ఉన్న సబ్నెట్లకు దూర ట్రాఫిక్ ఎంపికకారుడిని తగ్గించడం ప్రతి హోస్ట్కు ఒకేసారి ఘర్షణను తొలగిస్తుంది, దాని వ్యయం కొత్త భాగం కాదు, కీ పునర్ చర్చ.

వెడల్పాటి ఎంపికకారుడు ఉండాల్సి వచ్చినప్పుడు పాస్త్రూ మినహాయింపు శస్త్రచికిత్సా ఎంపిక. strongSwan తన child pass మోడ్ను ఉపయోగించే ప్రత్యేక కనెక్షన్ను మద్దతు ఇస్తుంది, అది సరిపోలే ట్రాఫిక్ను IPsec ప్రాసెస్ చేయకూడదని కెర్నల్కు చెబుతుంది. లూప్బ్యాక్ దూర చిరునామా ఆ కనెక్షన్ను వచ్చే సహచరుల కోసం ఎంపిక చేయకుండా నిరోధిస్తుంది, ఎంపికకారులు అన్నీ కాక, నిజమైన అధికార పొందిన జంటను వివరించాలి.

connections {
    openvpn-exception {
        remote_addrs = 127.0.0.1
        children {
            openvpn-exception {
                local_ts = 10.44.7.0/24
                remote_ts = 172.20.8.0/24
                mode = pass
                start_action = trap
            }
        }
    }
}

strongSwan కాన్ఫిగరేషన్ ఉదాహరణలు ఈ విధాన రకాన్ని మరియు లూప్బ్యాక్ సహచర సంప్రదాయాన్ని నమోదు చేస్తాయి. మూడో ఎంపిక XFRM ఇంటర్ఫేస్లతో మార్గ ఆధారిత డిజైన్, ఇది విధానాన్ని ప్రపంచ ఎంపికకారుడికి బదులు పేరు పెట్టిన ఇంటర్ఫేస్ ద్వారా రూట్ అయ్యే ట్రాఫిక్కు కట్టివేస్తుంది. ఇది ట్యూన్ కాదు, స్థానభ్రంశం, ట్రాఫిక్ ఇంకా చర్చించిన ఎంపికకారులను తీర్చాలి.

OptionUse it whenCost
Narrow the selectorThe broad prefix was convenienceA rekey and a policy review
Passthrough childThe broad selector must stayOne exception per intended pair
XFRM interfacePolicy should follow routingA design migration

మిగిలిన దాన్ని బలహీనపరచకుండా మినహాయింపును నిరూపించండి

మార్పు లోడ్ చేసిన తర్వాత మినహాయింపును మరియు రక్షితంగా ఉండాల్సిన సాధారణ గమ్యాన్ని పరీక్షించండి. రెండు దిశలను తనిఖీ చేసి, తర్వాత OpenVPN సొరంగాన్ని కూలదోసి మినహాయించిన ట్రాఫిక్కు ఏమి జరుగుతుందో నిర్ధారించండి. సొరంగం కింద ఉన్నప్పుడు ఆ ప్రిఫిక్స్ను నిశ్శబ్దంగా బహిరంగంగా పంపే మినహాయింపు సంఘటన సమయంలో కనుగొనాల్సినది కాదు, ఉద్దేశపూర్వకంగా తీసుకోవాల్సిన విధాన నిర్ణయం.

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

సంబంధిత వ్యాసాలు