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

నియమాల క్రమం మరియు కనెక్షన్ స్థితి వేర్వేరు లోపాలు

క్రమబద్ధమైన గొలుసులు పైనుంచి క్రిందకు మూల్యాంకనం చేయబడతాయి, తుది తీర్పును చేరుకునే మొదటి నియమం ఆ గొలుసు గుండా ప్రయాణాన్ని ముగిస్తుంది. జాగ్రత్తగా రాసిన లాక్‌డౌన్ నియమం పైన విశాలమైన అనుమతిని ఉంచండి, అప్పుడు లాక్‌డౌన్ నియమం కేవలం పత్రం అవుతుంది: అది సమితిలో ఉంది, దాని కౌంటర్ సున్నా, ఏ ప్యాకెట్ కూడా దాన్ని ఎప్పటికీ చేరుకోదు. అదే పాఠ్యాన్ని మరో గొలుసుకు వర్తింపజేసినా ఏమీ నిరూపించబడదు. nftables లో మూల గొలుసులు ప్రాధాన్యతలపై హుక్‌లకు జోడించబడతాయి, కాబట్టి ఒక గొలుసులోని అనుమతి మరో హుక్ లేదా ప్రాధాన్యతపై ఉన్న మరో గొలుసు అదే ప్యాకెట్‌ను చూడకుండా ఆపదు.

కనెక్షన్ ట్రాకింగ్ రెండవ లక్షణాన్ని సృష్టిస్తుంది, బయట నుంచి అది అలాగే కనిపిస్తుంది. ప్రవాహం స్థితి పట్టికలోకి వచ్చిన తర్వాత, గొలుసు పైభాగానికి దగ్గరగా ఉన్న established-or-related అనుమతి మీ కొత్త నియమం పరిగణించబడక ముందే తిరిగి వస్తుంది. NAT మ్యాపింగ్‌లకు కూడా అదే గుణం ఉంది: ప్రవాహం ప్రారంభమైనప్పుడు అనువాదం నిర్ణయించబడింది, కాబట్టి సవరించిన postrouting నియమం ఇప్పటికే నడుస్తున్న సెషన్‌ను తిరిగి రాయదు. అందుకే 09:00కి కొత్త కనెక్షన్‌కు మార్పు పని చేస్తున్నట్లు, 08:55కి ఎవరో తెరిచిన సెషన్‌కు ఏమీ చేయనట్లు కనిపిస్తుంది.

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

క్రియాశీల నియమ సమితిని చదవండి, మీరు సవరించిన ఫైల్ కాదు

కెర్నల్ ఇప్పుడు అమలు చేస్తున్న దానితో ప్రారంభించండి. ఎప్పుడూ వర్తింపజేయని సేవ్ చేసిన కాన్ఫిగరేషన్ ఆశ్చర్యకరంగా చాలా మారని ప్రవర్తనలను వివరిస్తుంది, దాన్ని మినహాయించడానికి ఒకే ఆదేశం సరిపోతుంది:

nft list ruleset
iptables-save

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

iptables -L FORWARD -v -n --line-numbers
nft list chain inet filter forward

నిజమైన పరీక్ష ప్రయత్నం తర్వాత సున్నా ప్యాకెట్లతో ఉన్న లాక్‌డౌన్ నియమం విధాన సమస్య కాదు, అది స్థాన సమస్య. దాన్ని కదిలించడం ఒక పంక్తి మార్పు, వాక్యనిర్మాణమే అసలు బగ్‌కు కారణమైంది. iptables లో -I ప్రారంభంలో చేరుస్తుంది, -A చివరలో జోడిస్తుంది; nftables లో insert నియమాన్ని గొలుసు ప్రారంభంలో ఉంచుతుంది, add చివరలో జోడిస్తుంది. నియమం గెలవాల్సి వస్తే, యాదృచ్ఛికంగా లోడ్ అయిన క్రమాన్ని నమ్మడం బదులు స్పష్టంగా చెప్పండి.

ప్రవాహం ట్రాక్ అవుతోందా అని నిరూపించండి

నియమాన్ని నిందించే ముందు, ట్రాఫిక్ అసలు ట్రాక్ చేయబడిన కనెక్షనా అని తనిఖీ చేయండి. మొత్తం స్థితి పట్టికను కుమ్మరించడం బదులు నిర్దిష్ట ప్రవాహం గురించి అడగండి:

conntrack -L -p tcp --dport 1194
conntrack -E -p tcp --dport 1194

జాబితా స్థితిని మరియు మిగిలిన సమయ పరిమితిని చూపుతుంది, ఈ విధంగా మీరు స్థాపించబడిన సెషన్‌ను కొత్త ప్రయత్నం నుంచి వేరు చేస్తారు; ఈవెంట్ మోడ్ జరిగిన వెంటనే నవీకరణలను ముద్రిస్తుంది, ఇది క్లయింట్‌ను మళ్లీ కనెక్ట్ చేస్తున్నప్పుడు ఉపయోగకరం. మీరు ఏదైనా తాకక ముందే ప్రవాహం స్థాపించబడిన స్థితిలో ఉంటే, ఫిల్టర్ నియమాల ఏ సవరణా దాని విధిని మార్చదు. ఇది ఫైర్‌వాల్‌లో బగ్ కాదు, ఇది స్థితితో కూడిన ఫిల్టరింగ్ ఒప్పందం.

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

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

తిరిగి వెళ్లే మార్గంతో కొత్త ప్రవాహం నుంచి పరీక్షించండి

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

తర్వాత స్థితి ఇప్పటికే కవర్ చేయలేని మార్పిడితో పరీక్షించండి. క్లయింట్‌ను డిస్‌కనెక్ట్ చేసి మళ్లీ కనెక్ట్ చేయండి, కొత్త ఐదు సమూహం ఏర్పడనివ్వండి, అది జరుగుతున్నప్పుడు రెండు చివరలను గమనించండి:

tcpdump -ni eth0 'tcp port 1194'
journalctl -k -n 50 --no-pager

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

నియమంతో పాటు ఉద్దేశాన్ని మరియు స్థానాన్ని నమోదు చేయండి

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

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

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