VPN మార్పు తర్వాత రౌటర్ నిర్వహణ పేజీ స్పందించడం ఎందుకు ఆపేస్తుంది

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

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

సొరంగం ఎప్పుడూ నిర్వహణ మార్గం కాదు

ఫార్వార్డింగ్ మరియు ఇన్‌పుట్ వేర్వేరు పనులు. "క్లయింట్ సొరంగం ద్వారా NAS-ను చేరుకోగలదా?" అనేది రౌటర్ గుండా వెళ్లే ప్యాకెట్ల గురించిన ఫార్వార్డింగ్ ప్రశ్న. "నేను రౌటర్ SSH పోర్టును తెరవగలనా?" అనేది రౌటర్‌కే చిరునామా చేసిన ప్యాకెట్ల గురించిన ఇన్‌పుట్ ప్రశ్న. ఫార్వార్డ్ చేసిన ట్రాఫిక్ కోసం రాసిన అనుమతి నియమం రెండో ప్రశ్నకు ఏమీ చేయదు, ట్రాఫిక్‌ను సంపూర్ణంగా మోసుకెళ్లే సొరంగం కూడా మీ నిర్వహణ సెషన్‌ను తిరస్కరించడానికి ఇదే సాధారణ కారణం.

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

మొదటి పొర: రౌటర్ స్వంత చిరునామాకు మార్గం ఉందా?

క్లయింట్‌లో ప్రారంభించి ప్యాకెట్ ఎక్కడికి వెళ్తుందో కర్నెల్‌ను అడగండి. Linux లో ip route get 10.6.0.1 ఎంచుకున్న మార్గం, బయటకు వెళ్లే ఇంటర్‌ఫేస్ మరియు మూల చిరునామాను ముద్రిస్తుంది. అది మీ ప్రొవైడర్ వైపు డిఫాల్ట్ మార్గాన్ని నివేదిస్తే, ప్యాకెట్ ఎప్పుడూ సొరంగంలోకి ప్రవేశించదు, రౌటర్‌లోని ఏ నియమం దాన్ని కాపాడలేదు.

సొరంగం వైపు ప్రశ్నకు తన స్వంత సంస్కరణ ఉంది. WireGuard AllowedIPs-ను క్రిప్టోకీ రూటింగ్ పట్టికగా పరిగణిస్తుంది: ప్రతి చివర పీర్ ఏ మూల చిరునామాలను ఉపయోగించవచ్చు, ఏ గమ్యాలు ఆ పీర్‌కు పంపబడతాయో ప్రకటిస్తుంది. క్లయింట్ నమోదులో రౌటర్ సొరంగ చిరునామా లేకపోతే, క్లయింట్‌కు అక్కడికి మార్గం లేదు. ఆ క్లయింట్ కోసం సర్వర్ నమోదు క్లయింట్ సొరంగ చిరునామాను కవర్ చేయకపోతే, ఏ ఫైర్‌వాల్ నియమాన్ని చూసే ముందే సర్వర్ ప్యాకెట్‌ను విసిరేస్తుంది.

విధానాన్ని డీబగ్ చేసే ముందు మీరు చేరుకోవాలనుకునే ఖచ్చితమైన చిరునామాను నిర్ధారించండి. పాత DNS రికార్డు లేదా మార్పుకు ముందు కాష్ చేసిన పొరుగు నమోదు రౌటర్ ఎప్పుడూ కలిగి లేని చిరునామాకు మిమ్మల్ని పంపుతుంది.

రెండో పొర: ఇన్‌పుట్ విధానం, ఫార్వార్డింగ్ విధానం కాదు

ఫైర్‌వాల్‌లు ప్యాకెట్ వచ్చే ఇంటర్‌ఫేస్‌పై నియమాలను మూల్యాంకనం చేస్తాయి. pfSense మరియు OPNsense లో ఇంటర్‌ఫేస్ ట్యాబ్ మరియు నియమాల క్రమం ఫైర్‌వాల్ స్వంత సేవలకు ట్రాఫిక్ అనుమతించబడిందో లేదో నిర్ణయిస్తాయి; LAN క్లయింట్లను ఇంటర్నెట్‌కు పంపే నియమం సొరంగ పీర్‌కు వెబ్ GUI తెరవడానికి అనుమతించే నియమం కాదు. firewall4 ఉన్న OpenWrt లో ప్రతి జోన్ ఇన్‌పుట్ విధానాన్ని కలిగి ఉంటుంది, option input 'ACCEPT' లేదా 'REJECT', ఇన్‌పుట్ REJECT ఉన్న జోన్‌లోని సొరంగ ఇంటర్‌ఫేస్ నిర్వహణ కనెక్షన్లను తిరస్కరిస్తుంది, కానీ ఫార్వార్డింగ్ అనుమతించబడితే ట్రాఫిక్‌ను ఇంకా ఫార్వార్డ్ చేస్తుంది.

కొత్త మార్గం పనిచేయడానికి యాంటీ-లాకౌట్ నియమాన్ని నిలిపివేయవద్దు. ఆ నియమం చెడు నియమం LAN నిర్వహణ చిరునామాను లాక్ చేయకుండా నిరోధిస్తుంది; ఇది LAN ఉపనెట్‌వర్క్‌ను రక్షిస్తుంది, మీరు ఇప్పుడే సృష్టించిన సొరంగ ఉపనెట్‌వర్క్‌ను కాదు. నిర్వాహకుడి మూలానికి ఒక సన్నని నియమాన్ని జోడించి భద్రతా వలను అలాగే వదిలేయండి. pfSense యొక్క నిర్వహణ ప్రాప్యత పత్రం ఆ నియంత్రణలు ఎక్కడ ఉన్నాయో వివరిస్తుంది.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

మూడో పొర: ఆ చిరునామాలో ఏదైనా వింటోందా?

సేవ అమలులో ఉన్నా ఒకే చిరునామాకు బంధించబడటం వల్ల చేరుకోలేకపోవచ్చు. OpenWrt యొక్క uhttpd /etc/config/uhttpd లో స్పష్టమైన శ్రవణ నమోదులను ఉంచుతుంది, ఉదాహరణకు list listen_http '0.0.0.0:80'; LAN చిరునామాకు మాత్రమే బంధించే నిర్మాణం సొరంగ చిరునామాలో ఏమీ అంగీకరించదు, శ్రవణ ఇంటర్‌ఫేస్ అమరికను చూపే ఉత్పత్తులు కూడా అలాగే ప్రవర్తిస్తాయి. పైన ఉన్న శ్రవణ ఆదేశాలు దీనికి నేరుగా సమాధానం ఇస్తాయి.

తర్వాత తిరస్కరణను నిశ్శబ్దం నుండి వేరు చేయండి. nc -vz 10.6.0.1 443 తిరస్కరించిన కనెక్షన్‌ను తిరిగి ఇస్తే ప్యాకెట్ రౌటర్‌ను చేరింది, ఏదో దాన్ని తిరస్కరించింది, మూసివేసిన పోర్టు లేదా స్పష్టమైన తిరస్కరణ నియమం. గడువు వరకు వేలాడటం ప్యాకెట్ విసిరివేయబడింది లేదా ఎప్పుడూ రూట్ చేయబడలేదు అని అర్థం. ఈ భేదం తర్వాత ఏ పొరను పరిశీలించాలో చెబుతుంది, దానికి ఐదు సెకన్లు పడుతుంది.

VPN ఇంటర్‌ఫేస్ ఒక సరిహద్దు, పునరుద్ధరణ మార్గం కాదు

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

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

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

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

విధానాన్ని తాకే ముందు తిరిగి వెళ్లే మార్గాన్ని సిద్ధం చేయండి

మొదటి మార్పుకు ముందు నాలుగు విషయాలను రాయండి: సొరంగం చనిపోతే మీరు పరికరాన్ని ఎలా చేరుకుంటారు, ఉదాహరణకు సీరియల్ కన్సోల్, ప్రొవైడర్ కన్సోల్ లేదా LAN లోని యంత్రం; ప్రస్తుత కాన్ఫిగరేషన్ ఎక్కడ ఎగుమతి అవుతుంది; మీరు మార్చబోయే ఒకే నియమం లేదా మార్గం; ఆ అంశాన్ని సరిగ్గా ఎలా తిరిగి తెస్తారు. OpenWrt లో sysupgrade -b /tmp/backup.tar.gz కాన్ఫిగరేషన్‌ను పట్టుకుంటుంది, మార్పులు uci commit వరకు పెండింగ్‌లో ఉంటాయి, సమయానికి గమనిస్తే చవకైన రద్దును ఇస్తుంది. pfSense కాన్ఫిగరేషన్ చరిత్రను ఉంచుతుంది, AutoConfigBackup ముందే ప్రారంభించబడి ఉంటే మాత్రమే సహాయపడుతుంది. రౌటర్ fail-closed నియమ సముదాయాన్ని నడిపిస్తే, మీరు ప్రణాళిక చేసిన నిర్వహణ మార్గం ఆ నియమం నిరోధించే ట్రాఫిక్‌లో లేదని నిర్ధారించండి, రీబూట్ శాశ్వత నియమాలను తొలగించడం బదులు మళ్లీ వర్తింపజేస్తుందని గుర్తుంచుకోండి.

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

బయలుదేరే ముందు శీఘ్ర తనిఖీ:

• మీరు ఇప్పుడే సవరించిన నియమంపై ఆధారపడని మూలం నుండి రౌటర్‌ను చేరుకోగలరా?
• సొరంగ ఇంటర్‌ఫేస్‌పై ఇన్‌పుట్ విధానం నిర్వాహకుడి మూలానికి మాత్రమే అనుమతి ఇస్తుందా?
• నిర్వహణ సేవ సొరంగంలో ఉన్న చిరునామాకు బంధించబడిందా?
• మీరు ఒక తిరస్కరించిన పీర్ మరియు ఒక కొత్త సెషన్‌ను పరీక్షించారా?
• WAN నిర్వహణ ఉపరితలం ఇంకా మూసి ఉందా?