VPN మార్గమా లేక ఫైర్‌వాల్ నియమమా: ప్యాకెట్‌ను ఎవరు పడేస్తున్నారు?
మార్గం ఒక దారిని ఎంచుకుంటుంది, ఫిల్టర్ అనుమతిని నిర్ణయిస్తుంది. ఫైర్‌వాల్ నియమాన్ని విస్తరించే ముందు అదే మూలం, గమ్యం మరియు దిశకు రెండింటినీ తనిఖీ చేయండి.
ఒకే ప్యాకెట్‌పై రెండు స్వతంత్ర నిర్ణయాలు జరుగుతాయి, వాటిలో ఏదైనా అభ్యర్థనను నిశ్శబ్దంగా ముగించగలదు. మార్గ శోధన ఒక ఇంటర్‌ఫేస్ మరియు తదుపరి హాప్‌ను ఎంచుకుంటుంది, ఆపై ప్యాకెట్ ఫిల్టర్ ఆ కలయిక అనుమతించబడిందో లేదో నిర్ణయిస్తుంది. సమయ ముగింపు రెండింటిలో ఒకటి తిరస్కరించిందని, ఏది అని కాదు అని మీకు చెబుతుంది. దశలను క్రమంగా చేయండి, మరమ్మతు సాధారణంగా ఊహగా ఉండటం ఆపేస్తుంది.
రెండు నిర్ణయాలు, ఒక ప్యాకెట్, ఇద్దరు యజమానులు
మార్గ శోధన మొదట విధాన నియమాలను సంప్రదిస్తుంది, తర్వాత అవి సూచించే పట్టికను, మరియు గమ్యంతో సరిపోయే అత్యంత నిర్దిష్ట ప్రిఫిక్స్‌ను ఎంచుకుంటుంది. టన్నెల్ మార్గాన్ని ఇన్‌స్టాల్ చేసిన క్లయింట్ ఆ నిర్ణయానికి యజమాని, ఫైర్‌వాల్ నియమంలో ఏదీ దానిని భర్తీ చేయలేదు. శోధన ఊహించని ప్రదేశాన్ని సూచించినప్పుడు, ప్రతి తదుపరి దశ తప్పు ప్యాకెట్‌పై పని చేస్తుంది.
ఫిల్టరింగ్ వేరు. Linux హోస్ట్‌లో netfilter హుక్‌లు ప్యాకెట్ ఎవరికోసం అన్న దాని ఆధారంగా ట్రాఫిక్‌ను విభజిస్తాయి: అవుట్‌పుట్ యంత్రాన్ని విడిచిపోతుంది, ఇన్‌పుట్ దానిపై ముగుస్తుంది, ఫార్వర్డ్ దాని గుండా వెళుతుంది. VPN క్లయింట్లను అంగీకరించి వాటిని LANకి మార్గనిర్దేశం చేసే గేట్‌వేకు ఫార్వర్డ్ మార్గం అవసరం, మరియు చాలా డిఫాల్ట్ కాన్ఫిగరేషన్లు ఖాళీగా వదిలే గొలుసు అదే.
మూల ఎంపిక అదే నిర్ణయానికి చెందుతుంది, అక్కడే చాలా అసమానతలు దాగి ఉన్నాయి. మార్గం ఒకదాన్ని పేర్కొనకపోతే కర్నెల్ బయటకు వెళ్లే ఇంటర్‌ఫేస్ నుండి మూల చిరునామాను ఎంచుకుంటుంది, కాబట్టి LAN సబ్‌నెట్ కోసం రాసిన ఫిల్టర్ నియమం టన్నెల్ చిరునామాతో బయటకు వెళ్లే ప్యాకెట్‌తో ఎప్పటికీ సరిపోదు.
శోధన వాస్తవంగా ఏమి ఎంచుకుందో చదవండి
నిర్ణయాన్ని ఊహించకుండా ముద్రించండి. క్రింది ఆదేశం ఆ గమ్యానికి కర్నెల్ ఉపయోగించే మార్గాన్ని, ఇంటర్‌ఫేస్ మరియు ఎంచుకునే మూలంతో సహా పరిష్కరిస్తుంది:
ip route get 10.8.0.5 ip route get 10.8.0.5 from 192.0.2.44 ip rule show ip route show table all | sed -n '1,40p'
VPN క్లయింట్లు తరచుగా ప్రధాన పట్టికకు దిగువ ప్రాధాన్యతలలో విధాన నియమాలను ఇన్‌స్టాల్ చేస్తాయి, కాబట్టి శుభ్రమైన ప్రధాన పట్టిక తనంతట తాను ఏమీ నిరూపించదు. నియమాల ప్రాధాన్యతలను అవి ఎంచుకునే పట్టికలతో పోల్చండి, మరియు టన్నెల్ మార్గం ఒకసారి చేతితో జోడించబడే బదులు తిరిగి కనెక్ట్ అయిన తర్వాత కొనసాగుతుందో లేదో తనిఖీ చేయండి.
విధాన ఆధారిత IPsec రూటింగ్ కవర్ చేయని మూడవ సరిపోలిక దశను జోడిస్తుంది, strongSwan యొక్క ఫార్వర్డింగ్ గమనికలు టన్నెల్ మరియు రవాణా సెటప్‌లకు వివరించినట్లు. భద్రతా విధానం ట్రాఫిక్‌ను ప్రిఫిక్స్ మరియు ప్రోటోకాల్ ద్వారా ఎంచుకుంటుంది, మార్గం రక్షించబడని ప్యాకెట్ ఎక్కడికి వెళుతుందో మాత్రమే నిర్ణయిస్తుంది. మార్గనిర్దేశం చేయబడినా సరిపోయే ఎంపికదారు లేని సబ్‌నెట్ రక్షణ లేకుండా ఉంటుంది లేదా కాన్ఫిగరేషన్‌ను బట్టి విసిరివేయబడుతుంది, ఏ ఫలితం ఫైర్‌వాల్ సమస్యలా కనిపించదు. విధానాన్ని ముద్రించి దాని ఎంపికదారులను టన్నెల్ మోస్తుందని మీరు ఆశించిన ప్రిఫిక్స్‌లతో పోల్చండి.
ఫిల్టరింగ్ హుక్‌పై వర్తిస్తుంది, మార్గంపై కాదు
VPN శ్రోతను అనుమతించే నియమం గేట్‌వేకే చిరునామా చేయబడిన ట్రాఫిక్ గురించిన నియమం. ఆ గేట్‌వే వెనుక ఉన్న హోస్ట్‌లను చేరుకునే క్లయింట్ల గురించి అది ఏమీ చెప్పదు, ఎందుకంటే ఫార్వర్డ్ చేయబడిన ట్రాఫిక్ వేరే గొలుసు గుండా వెళుతుంది. నియమాల సముదాయాన్ని ఒక చదునైన జాబితాగా చదవడమే సరైనదిగా కనిపించే నియమం ఎప్పటికీ మండని సాధారణ కారణం.
కౌంటర్లు ప్రశ్నను త్వరగా పరిష్కరిస్తాయి. సున్నా ప్యాకెట్ లెక్క ఉన్న నియమాన్ని ఎప్పటికీ చేరుకోలేదు, ఇది తప్పు గొలుసు, తప్పు ఇంటర్‌ఫేస్ లేదా మునుపటి విసిరివేతను సూచిస్తుంది. విసిరివేత విధానం కింద లెక్క పెరుగుతున్న నియమమే మీరు వెతుకుతున్న సరిహద్దు, మరియు ప్యాకెట్ తప్పుగా మార్గనిర్దేశం చేయబడే బదులు విసిరివేయబడుతోంది.
క్లయింట్ ఉపయోగించే మార్గం ద్వారా ఒక ప్రోబ్ పంపండి
గేట్‌వేపైనే నడిచే పరీక్షలు గేట్‌వే యొక్క స్వంత మూల చిరునామాతో అవుట్‌పుట్ మరియు ఇన్‌పుట్ గుండా వెళతాయి. అది క్లయింట్ యొక్క ఫార్వర్డ్ చేయబడిన అభ్యర్థనకు భిన్నమైన మార్గం, కాబట్టి విజయవంతమైన స్థానిక curl కనిపించిన దానికంటే తక్కువ నిరూపిస్తుంది. విఫలమయ్యే యంత్రం నుండి పరీక్షించండి, లేదా ఇంటర్‌ఫేస్ మరియు మూలాన్ని స్పష్టంగా పిన్ చేయండి.
nc -vz -w 3 10.8.0.5 443 ping -c 3 -W 1 10.8.0.5 tcpdump -ni any host 10.8.0.5 and port 443 iptables -vnL FORWARD --line-numbers nft list ruleset | sed -n '1,60p'
రెండు చివరల్లో క్యాప్చర్ మిగిలిన కేసులను వేరు చేస్తుంది. క్లయింట్‌ను విడిచిపెట్టి ఎప్పటికీ చేరుకోని SYN అంటే రూటింగ్, ఎన్‌క్రిప్షన్ లేదా ఎగువ యాక్సెస్ జాబితా. చేరుకుని ప్రతిస్పందన పొందని SYN అంటే సేవ లేదా దాని హోస్ట్ ఫిల్టర్, మరియు టన్నెల్ ఎప్పటికీ సమస్య కాదు.
తిరిగి వచ్చే ట్రాఫిక్ తనకంటూ ఒక చూపును అర్హం. అసమాన రూటింగ్ మరియు విలోమ మార్గ ఫిల్టరింగ్ తప్పు ఇంటర్‌ఫేస్‌పై వచ్చే ప్రతిస్పందనలను విసిరివేస్తాయి, ఇది నిరోధించబడిన పోర్ట్‌కు బదులు ఏకదిశా కనెక్షన్‌గా కనిపిస్తుంది. ఫైర్‌వాల్ సృష్టించని లక్షణానికి దానిని నిందించే ముందు sysctl విలువను తనిఖీ చేయండి.
లాగింగ్ మొదటి అడుగు కాదు, రెండవ అభిప్రాయంగా పని చేస్తుంది. ఫార్వర్డ్ గొలుసుపై తాత్కాలిక లాగ్ ప్రకటన దానిని తాకిన ఇంటర్‌ఫేస్ మరియు చిరునామాలను పేర్కొంటుంది, తర్వాత తీసివేయడం సులభం. దానిని శాశ్వతంగా ఉంచితే సమాధానానికి బదులు లాగ్ పరిమాణ సమస్యను నిర్మించారు.
ప్రతి మార్పును తిరిగి కనెక్ట్ అయిన తర్వాత కొనసాగే చోట ఉంచండి
ip route add ద్వారా జోడించిన మార్గం ఇంటర్‌ఫేస్ క్రిందికి వెళ్లే వరకు జీవిస్తుంది. దానిని కనెక్షన్ ప్రొఫైల్‌లో సేవ్ చేయండి: NetworkManager కనెక్షన్‌పై అదనపు మార్గాలను అంగీకరిస్తుంది, netplan వాటిని బూట్ల మధ్య ఉంచుతుంది. అదే నియమం క్లయింట్ వైపు ఫైర్‌వాల్ మినహాయింపుకు కూడా వర్తిస్తుంది, అది తదుపరి రీలోడ్ తర్వాత పోతుంది.
సర్వర్ వైపు నియమాలు సేవ ప్రారంభంలో లోడ్ చేసే కాన్ఫిగరేషన్ ఫైల్‌కు చెందుతాయి, మీరు మూసినప్పుడు ముగిసే ఇంటరాక్టివ్ సెషన్‌కు కాదు. నియమాన్ని రాయండి, రీలోడ్ చేయండి, మరియు కౌంటర్ కదిలిందని నిర్ధారించండి, ఎందుకంటే సింటాక్స్‌ను తిరస్కరించిన రీలోడ్ పాత నియమాల సముదాయాన్ని నిశ్శబ్దంగా దాని స్థానంలో ఉంచుతుంది.
తర్వాత అసలు అప్లికేషన్ అభ్యర్థనను మొదటి నుండి చివరి వరకు పునరావృతం చేసి ఏ పొర మారిందో నమోదు చేయండి. ఫిల్టర్ మార్పు కూడా అవసరమైన మార్గ మరమ్మతు అయినా విఫలమవుతుంది, మొదటిది పోయిందని తెలిసిన తర్వాత రెండవ వైఫల్యాన్ని చదవడం చాలా సులభం. ఫలితం పక్కన తేదీ మరియు క్లయింట్ వెర్షన్‌ను నమోదు చేయండి, ఎందుకంటే రూటింగ్ మరియు ఫిల్టరింగ్ రెండింటి డిఫాల్ట్‌లు విడుదలల మధ్య కదులుతాయి. ఆ గమనికను టికెట్‌పై ఉంచండి, తదుపరి వ్యక్తి రెండు-దశల ప్రయాణాన్ని పునరావృతం చేయకుండా మీరు ఆగిన చోటి నుండి ప్రారంభించేలా.