VPN స్థితికి కట్టుబడిన ఫైర్‌వాల్ గేట్ టన్నెల్ ద్వారా మాత్రమే ping నియమం ఎందుకు కాదు

పేరు పెట్టిన VPN ప్రొఫైల్ కనెక్ట్ అయిన ప్రతిసారీ సర్వర్ పబ్లిక్ చిరునామా కోసం ICMP echo ను ఆన్ చేసే ఫైర్‌వాల్ నియమాన్ని ఊహించండి. ఇది «టన్నెల్ ద్వారా మాత్రమే ping» గా చదవబడుతుంది, ఆ పఠనం ముఖ్యమైన విధంగా తప్పు. నియమం ఎవరు హోస్ట్‌ను చేరుకోగలరో పరిమితం చేయదు; మరో కనెక్షన్ యాదృచ్ఛికంగా పనిచేస్తున్నప్పుడు పబ్లిక్ ఇంటర్‌ఫేస్ ఏమి సమాధానమిస్తుందో మారుస్తుంది. ఇవి రెండు వేర్వేరు విధానాలు, వాటిలో ఒకటి నిశ్శబ్దంగా బహిర్గతతను విస్తరిస్తుంది.

మీరు రాశారని అనుకునే నియమం

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

షరతు మూల చిరునామా కాకుండా కనెక్షన్ స్థితి అయిన క్షణం, అనుమతించిన పంపేవారి సమితి ఇకపై VPN సహచరుల సమితి కాదు. పబ్లిక్ చిరునామాన్ని చేరుకోగల ఎవరైనా గేట్ తెరిచి ఉన్నప్పుడు echo అభ్యర్థన పంపవచ్చు. టన్నెల్ మార్గం కాలేదు; టన్నెల్ స్విచ్ అయింది.

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

గేట్ నిజంగా ఏమి నియంత్రిస్తుంది

ఈ రూపకల్పన రెండు స్వతంత్ర విషయాలను కలిపేస్తుంది, వాటిని వేరు చేయడమే సవరణలో ఎక్కువ భాగం. మొదటిది పరిధి: ఏ స్థానిక చిరునామా, ఏ దూర చిరునామాలు, ఏ ప్రోటోకాల్ మరియు ఏ ICMP రకం. రెండవది షరతు: నియమం యొక్క ఆబ్జెక్ట్ ఈ క్షణం ప్రారంభించబడిందా. పరిధిని ఫైర్‌వాల్ ప్రతి ప్యాకెట్‌కు అంచనా వేస్తుంది; షరతును స్క్రిప్ట్ విధాన నిల్వలో రాస్తుంది, రెండూ పూర్తిగా వేర్వేరు గడియారాలపై సమన్వయపరచబడతాయి.

అవసరం నిజంగా VPN సహచరులు మాత్రమే అయితే, ఏ కనెక్షన్-స్థితి తర్కం లేకుండా పరిధి దానికి సమాధానమిస్తుంది: నియమాన్ని టన్నెల్ ఇంటర్‌ఫేస్‌కు లేదా టన్నెల్ చిరునామా పరిధికి కట్టండి, దూర చిరునామాలను క్లయింట్ పూల్‌కు పరిమితం చేయండి, «ICMP» బదులు echo రకాన్ని పేర్కొనండి. ఏ VPN లేనప్పుడు కూడా ఆ నియమం సరిగ్గా ఉంటుంది, సంబంధం లేని ప్రొఫైల్ దాన్ని తెరవలేదు.

అవసరం నిజంగా పబ్లిక్ గేట్ అయితే, ఆమోద ప్రమాణాలు మారుతాయి కాబట్టి దాన్ని విధాన పాఠ్యంలో చెప్పండి. పబ్లిక్ గేట్ ఖచ్చితమైన ప్రొఫైల్‌ను పేర్కొనాలి, «కనెక్ట్ అయింది» అంటే ఏమిటో నిర్వచించాలి, పబ్లిక్ పంపేవారు రూపకల్పన ప్రకారం పరిధిలో ఉన్నారని ప్రకటించాలి. ఎవరో ఆ వాక్యాన్ని రాయవలసి వచ్చిన క్షణంలో చాలా గందరగోళం మాయమవుతుంది.

ఆబ్జెక్ట్‌ను ఒకసారి నిర్మించి, తర్వాత టోగుల్ చేయండి

స్థిర గుర్తింపుతో ఒక నియమాన్ని ముందుగానే, నిష్క్రియంగా సిద్ధం చేయండి, నియంత్రకం దాని సక్రియ స్థితిని మాత్రమే మార్చనివ్వండి. ప్రతి అమలులో ప్రదర్శన పేరుతో నియమాలను సృష్టించడమే విధాన నిల్వ ఐదు దాదాపు ఒకేలాంటి ఆబ్జెక్టులతో, వాటిని తొలగించే నమ్మకమైన మార్గం లేకుండా ముగిసే దారి.

New-NetFirewallRule -Name "VpnGateEchoV4" -DisplayName "Public echo gated on VPN state" -Direction Inbound -Action Allow -Protocol ICMPv4 -IcmpType 8 -LocalAddress 203.0.113.10 -RemoteAddress Any -Enabled False
Set-NetFirewallRule -Name "VpnGateEchoV4" -Enabled True

పేరు శాశ్వత గుర్తింపుదారు; ప్రదర్శన పేరు మనిషి సవరించగల పత్రం. -Name పై సమన్వయపరచండి, స్క్రిప్ట్ నకళ్లను తయారు చేయడం ఆపుతుంది. అదే ఆదేశ రూపం IPv6 కేసును -Protocol ICMPv6 -IcmpType 128 తో కవర్ చేస్తుంది, కానీ అది వేరు నియమం, ఎందుకంటే echo రకం సంఖ్యలు రెండు కుటుంబాల మధ్య భిన్నంగా ఉంటాయి.

చిరునామా కుటుంబం మరియు ICMP రకాన్ని స్పష్టంగా ఉంచండి, రెండవ కారణం కూడా ఉంది: -Protocol ICMPv4 రకం లేకుండా ప్రొఫైల్ అనుమతించే ప్రతి ICMPv4 సందేశాన్ని అనుమతిస్తుంది, మీరు ఎప్పుడూ స్వీకరించాలని అనుకోని వాటితో సహా. రకం 8 పేర్కొనడం నియమాన్ని echo అభ్యర్థనకు సంకోచిస్తుంది, చేరిక తనిఖీ పంపేది అది మాత్రమే.

స్వయంచాలకత నీతికి విరుద్ధమయ్యే చోటు

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

స్థితి తనిఖీలోనే పరిధి ఉచ్చు ఉంది. Get-VpnConnection యంత్రంలో కాన్ఫిగర్ చేసిన క్లయింట్ ప్రొఫైల్‌లను నివేదిస్తుంది, డిఫాల్ట్‌గా ప్రస్తుత వినియోగదారుకు మరియు -AllUserConnection తో అందరు వినియోగదారులకు. ఇప్పుడు RRAS సర్వర్‌కు డయల్-ఇన్ అయిన దూర వినియోగదారులను అది నివేదించదు; అది మరో ఆదేశంతో చేసే మరో పరిశీలన. తప్పుదానిపై నిర్మించిన గేట్ ఏదీ కనెక్ట్ కాలేదు.

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

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