strongSwan లో పూర్తి టన్నెల్‌కు రెండు వైపులా 0.0.0.0/0 అవసరం

ఒక ప్రైవేట్ సబ్‌నెట్‌కు పనిచేసే strongSwan కనెక్షన్, ఎవరో ఒక లైన్ సవరించారని మాత్రమే ఇంటర్నెట్ ట్రాఫిక్‌ను మోసుకెళ్లదు. పూర్తి టన్నెల్ అంటే child SA ఏ చిరునామాలను రక్షిస్తుందనే దానిపై రెండు పక్షాల మధ్య ఒప్పందం, మరియు ప్రతి పక్షం మరొకదాన్ని తనను బట్టి పేర్కొంటుంది. ఒక వైపు సరిగా, మరొక వైపు తప్పుగా చేస్తే child SA గానీ లేవదు లేదా ఉద్దేశించిన దానికంటే ఇరుకుగా లేస్తుంది. క్రింది ఐదు తనిఖీలు ఆ ఒప్పందాన్ని క్లయింట్ నుండి గేట్‌వే ద్వారా ఇంటర్నెట్ వరకు అనుసరిస్తాయి.

మొదట క్లయింట్ సెలెక్టర్‌ను తనిఖీ చేయండి

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

children {
    net {
        local_ts  = dynamic
        remote_ts = 0.0.0.0/0
    }
}

ఈ భాగం పూర్తి కనెక్షన్ ఫైల్ కాదు, మరియు ఇది ప్రామాణీకరణ, గుర్తింపులు మరియు వర్చువల్ చిరునామాల సమూహం ఇప్పటికే కాన్ఫిగర్ చేయబడ్డాయని ఊహిస్తుంది. క్లయింట్ మూల సెలెక్టర్ మరియు సర్వర్ కేటాయించే చిరునామా ఇప్పటికీ సరిపోలాలి, లేకపోతే child SA ఏ పక్షం ఊహించని పరిధితో లేస్తుంది. దాన్ని swanctl --load-all తో లోడ్ చేసి విజయాన్ని ఊహించే ముందు అవుట్‌పుట్ చదవండి. పార్స్ అయ్యే ఫైల్ కూడా మరొక పక్షం ప్రతిపాదనతో పొంతన లేని సెలెక్టర్ కారణంగా తిరస్కరించబడవచ్చు.

గేట్‌వే సెలెక్టర్‌ను దాని స్వంత వైపు తనిఖీ చేయండి

గేట్‌వే అదే భావనను వ్యతిరేక దిశ నుండి చదువుతుంది. ఇంటర్నెట్ గమ్యాలు గేట్‌వేకు స్థానికం, కాబట్టి దాని local_ts వెడల్పైనది మరియు remote_ts క్లయింట్ సమూహాన్ని వివరిస్తుంది. ఈ తలకిందుల మార్పు పూర్తి-టన్నెల్ కాన్ఫిగరేషన్‌లో అత్యంత సాధారణ పొరపాటు, మరియు రెండు లైన్లు విడివిడిగా నమ్మదగినవిగా కనిపించడం వల్ల ఇది సమీక్షను దాటుతుంది.

children {
    rw {
        local_ts  = 0.0.0.0/0
        remote_ts = 10.77.0.0/24
    }
}

క్లయింట్ భాగాన్ని గేట్‌వే ఫైల్‌లోకి కాపీ చేయడం ఉపయోగకరమైన ఏదీ వివరించని సెలెక్టర్ జంటను సృష్టిస్తుంది, ఎందుకంటే రెండు పక్షాలు ఒకే పాత్రను క్లెయిమ్ చేస్తాయి. strongSwan ఫార్వర్డింగ్ మార్గదర్శిని క్లయింట్ మరియు గేట్‌వే జతను స్పష్టంగా నమోదు చేస్తుంది, మరియు దాన్ని వైఫల్యం తర్వాత కాదు, కనెక్షన్ ఫైల్ పక్కన చదవడం విలువైనది. గేట్‌వే ఫైల్‌కు remote_ts సూచించే సమూహం నిర్వచనం కూడా అవసరం. లేని సమూహాన్ని పేర్కొనే సెలెక్టర్ ఫిర్యాదు లేకుండా లోడ్ అవుతుంది మరియు కనెక్ట్ అయ్యేటప్పుడు విఫలమవుతుంది.

పాత ipsec.conf వేర్వేరు కీలతో ఎడమ మరియు కుడి పాత్రలను ఉపయోగిస్తుంది, మరియు rightsubnet లైన్ swanctl విలువకు నేరుగా ప్రత్యామ్నాయం కాదు. ఒకదాన్ని మరొకదానిలో అతికించడం బదులు రెండు సింటాక్స్‌లను వేర్వేరు ఫైళ్లలో ఉంచండి. వాటిని ఒకే డైరెక్టరీలో కలపడమే పనిచేస్తున్న కనెక్షన్ రీబూట్ తర్వాత నిశ్శబ్దంగా వెనక్కి తగ్గే మార్గం.

ఫైల్ కాదు, చర్చించిన child SA తనిఖీ చేయండి

సేవ్ చేసిన కాన్ఫిగరేషన్ ఉద్దేశాన్ని మాత్రమే నిరూపిస్తుంది, అంతకు మించి ఏమీ లేదు. మరొక పక్షం అడిగిన దాన్ని ఇరుకు చేయవచ్చు, మరియు దాని క్రింద ఫైల్ మారిందని మాత్రమే ఉన్న child SA భర్తీ చేయబడదు. మరేదైనా మార్చే ముందు నిజంగా ఏమి ఇన్‌స్టాల్ చేయబడిందో నిర్ధారించండి.

swanctl --list-conns
swanctl --list-sas
ip xfrm policy list

మొదటి ఆదేశం డీమన్ ఏమి లోడ్ చేసిందో చూపిస్తుంది, రెండవది ఏర్పాటైన child SA లను చూపిస్తుంది, మూడవది కెర్నల్ వర్తించే విధానాలను చూపిస్తుంది. ఫైల్ 0.0.0.0/0 అని చెప్పి జాబితా ఒక సబ్‌నెట్ చూపిస్తే, చర్చలు పరిధిని ఇరుకు చేశాయి మరియు ఫైల్ తిరిగి చదవడం దాన్ని వివరించదు. child ను ఆపి మళ్లీ ప్రారంభించి మూడు అవుట్‌పుట్‌లను మళ్లీ పోల్చండి. అదే ఇరుకు పరిధితో తిరిగి వచ్చే child స్థానిక ఫైల్ వల్ల కాదు, దూరపు పక్షం వల్ల ఇరుకు చేయబడుతోంది, మరియు అది స్థానిక సవరణ కాదు, మరొక నిర్వాహకుడితో సంభాషణ.

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

ఫార్వర్డింగ్ మరియు తిరిగి వచ్చే మార్గాన్ని తనిఖీ చేయండి

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

sysctl net.ipv4.ip_forward
iptables -t nat -S | grep -i masq
ip route get 1.1.1.1

ప్రైవేట్ క్లయింట్ చిరునామాలు సాధారణంగా పబ్లిక్ ఇంటర్‌ఫేస్‌ను విడిచే ముందు ఉద్దేశపూర్వక మూల అనువాదం అవసరం, అయితే స్పష్టంగా రూట్ చేయబడిన కేటాయింపుకు వేరే విధానం అవసరం. NAT పాల్గొంటే, భద్రతా విధానం తనిఖీ చేయవలసిన ట్రాఫిక్ దాన్ని దాటి అనువదించబడకుండా అమలు మద్దతు ఇచ్చే మినహాయింపులను ఉంచండి. మరొక గేట్‌వే నుండి కాపీ చేసిన విస్తృత masquerade నియమం రచయిత ఉద్దేశించిన దానికంటే చాలా ఎక్కువ ప్రవాహాలను మారుస్తుంది. నియమాన్ని క్లయింట్ సమూహానికి మాత్రమే రాయండి, మరియు అది ఎందుకు ఉందో వివరించే వ్యాఖ్యను వదిలేయండి.

క్లయింట్‌లో మీరు ఊహించిన మార్గాలను కాదు, backend ఇన్‌స్టాల్ చేసిన మార్గాలను నిర్ధారించండి. మార్గ స్థాపన నిలిపివేయబడిన నిర్వాహకుడికి చేతితో నిర్వహించే రూటింగ్ డిజైన్ అవసరం, మరియు టన్నెల్ మారినప్పుడల్లా ఆ డిజైన్ నవీకరించాలి. మళ్లీ కనెక్ట్ అయిన తర్వాత రూటింగ్ పట్టికను తనిఖీ చేయండి, కొత్త బూట్ తర్వాత మాత్రమే కాదు.

టన్నెల్ ఇంకా ఏమి కవర్ చేయలేదో తనిఖీ చేయండి

సెలెక్టర్ జంట IPv4 ను మాత్రమే కవర్ చేస్తుంది, మరేదీ కాదు. IPv6, DNS మరియు ఏదైనా అప్లికేషన్-స్థాయి విధానం వేర్వేరు నిర్ణయాలు, విస్తృత IPv4 సెలెక్టర్ వాటిని నిశ్శబ్దంగా పట్టించుకోదు. ప్రతి IPv4 ప్యాకెట్‌ను మోసే టన్నెల్ కూడా ప్రతి పేరు శోధనను లీక్ చేయవచ్చు.

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

resolvectl query intranet.example.internal
traceroute -n 1.1.1.1

పై జాబితా నుండి చర్చించిన సెలెక్టర్లతో పాటు ఆ రెండు ఆదేశాలతో గొలుసును నిర్ధారించండి. traceroute స్థానిక రూటర్‌ను మొదటి హాప్‌గా చూపిస్తే, సెలెక్టర్లు ఏమి చెప్పినా ట్రాఫిక్ టన్నెల్‌ను ఉపయోగించడం లేదు. ఇంటర్నెట్ యాక్సెస్ ఎంచుకున్న ట్రాఫిక్ రూపొందించిన గేట్‌వే ద్వారా అంగీకరించబడి, ఫార్వర్డ్ చేయబడి, తిరిగి తీసుకురాబడినప్పుడే పూర్తవుతుంది. ప్రొఫైల్‌లో 0.0.0.0/0 కనుగొనడం ఆ గొలుసు ప్రారంభం, దాని రుజువు కాదు.