MikroTik VPN वापरकर्ता खूप दूर पोहोचतो: एका होस्ट आणि एका पोर्टपर्यंत मर्यादित करा

टनेल वर येते, लॉगिन यशस्वी होते, आणि नेटवर्कवरील प्रत्येक होस्ट प्रतिसाद देते। हे तुटलेले VPN नाही; हे परवानगी-मॉडेल नसलेले VPN आहे। RouterOS खात्याची प्रमाणिकता तपासते आणि नंतर त्याची पॅकेट्स इतरांसारखीच मार्गक्रमण करते, म्हणून मर्यादा फायरवॉलने पुरवली पाहिजे। लॉगिन न तोडता ती मर्यादा जोडणे हेच संपूर्ण काम आहे।

प्रमाणीकरण तिथे संपते जिथे परवानगी सुरू होते

PPP सत्र वर आल्यावर क्लायंटची पॅकेट्स इतर कोणत्याही इंटरफेसच्या रहदारीप्रमाणे forward साखळीत प्रवेश करतात। जर राउटरचे forward धोरण परवानगी देणारे असेल, तर सल्लागाराला लॉगिनच्या वेळी ती परवानगी वारशाने मिळते। खात्याने कधीही कोणतीही व्याप्ती बाळगली नाही, म्हणून खात्यावर बदलण्यासारखे काही नाही। नियमसंच कर्मचाऱ्यांसाठी लिहिला होता आणि नवे सत्र त्यात सहभागी झाले।

काहीही लिहिण्यापूर्वी विनंती कोणत्या मार्गाची आहे ते तपासा। राउटरच्या मागील होस्टकडे जाणारी रहदारी forward मधून जाते, तर राउटरकडेच जाणारी रहदारी, winbox आणि SSH सह, input मधून जाते। फक्त forward व्यापणारी व्याप्ती उपकरण त्याच क्लायंटसाठी उघडे ठेवते।

दोन्ही साखळ्यांना निर्णय हवा, निर्णय input बंद ठेवण्याचा असला तरी। ती निवड प्रवेश विनंतीची आहे, नंतरच्या विचाराची नाही।

सत्र नावाच्या यादीशी जोडा

PPP प्रोफाइल सत्र सुरू होताना देत असलेला पत्ता नावाच्या पत्त्यांच्या यादीत ठेवू शकते। यामुळे तात्पुरता टनेल पत्ता फायरवॉल नावाने जुळवू शकेल अशा गोष्टीत बदलतो, आणि सत्र संपल्यावर नोंद अदृश्य होते। मग खाते आपल्या प्रोफाइलकडून व्याप्ती वारशाने घेते, पत्ता कठोरपणे कोड करणाऱ्या नियमाकडून नाही।

आधी प्रोफाइल तयार करा, मग secret स्पष्टपणे त्याला जोडा। डीफॉल्ट प्रोफाइलकडे अजूनही निर्देश करणारा secret मूळ समस्या पुन्हा निर्माण करतो।

प्रोफाइल आणि यादीला अशी नावे द्या की त्यांची कामे स्पष्ट होतील, आणि दोन्हींवर विनंतीच्या संदर्भासह टिप्पणी करा। एक प्रोफाइल एकाच व्याप्तीच्या अनेकांना सेवा देऊ शकते, तर यादी प्रत्येक जिवंत सत्र ओळखत राहते। प्रत्येक व्यक्तीसाठी एका नियमापेक्षा हे पुनरावलोकनास स्वस्त आहे।

/ppp profile add name=scoped-consultant remote-address=consultant-pool address-list=vpn-scoped-clients
/ppp secret add name=consultant password=... service=ovpn profile=scoped-consultant

परवानगी दिलेली सेवा एका यादीत नोंदवा

परवानगी दिलेला सर्व्हर फिल्टर नियमात पत्ता रुजवण्याऐवजी त्याच्या स्वतःच्या पत्त्यांच्या यादीत ठेवा। यादीचे ऑडिट, विस्तार आणि टिप्पणी करता येते, आणि सर्व्हर हलल्यावर ती वापरणारा नियम बदलत नाही। एकच नोंद दुसरा होस्ट येईपर्यंत जास्त वाटते, आणि तो सहसा येतो।

पत्ता गतिमान किंवा भार-विभाजित असल्यास यादी जुळवा, आणि राखीव व स्थिर असल्यास पत्ता थेट जुळवा। टिप्पणी सेवा आणि मालकाचे नाव घेतल्यास दोन्हीपैकी कोणतीही निवड स्पष्ट वाचता येते।

होस्टसोबतच प्रोटोकॉल आणि पोर्टही मर्यादित करा। पोर्ट निर्बंध नसलेल्या होस्टसाठीचे accept तो होस्ट चालवत असलेली प्रत्येक सेवा उघडते, जे बहुतेक प्रवेश विनंत्या हेतू धरतात त्यापेक्षा विस्तृत आहे। पोर्ट परवानगीचा भाग आहे, नंतर जोडायचा तपशील नाही।

/ip firewall address-list add list=vpn-targets address=10.0.0.10 comment="consultant RDP target"

कोणत्याही विस्तृत accept आधी उडीची मांडणी करा

उडीचा नियम मर्यादित यादीतून पुढे पाठवलेली रहदारी अशा खाजगी साखळीत पाठवतो जिथे संपूर्ण धोरण तीन ओळींत बसते। पहिला नियम परवानगी दिलेले गंतव्य आणि पोर्ट स्वीकारतो, आणि शेवटचा नियम बाकी सर्व टाकून देतो। उडी forward मधील कोणत्याही विस्तृत accept वर असली पाहिजे, कारण आधीचे accept म्हणजे उडी कधीही चालत नाही। परतीची रहदारी वाहत राहावी म्हणून established आणि related चे accept उडीपूर्वी ठेवा।

कोणताही fasttrack नियम ही रहदारी मर्यादित साखळीच्या पलीकडे नेऊ शकत नाही याची खात्री करा। Fasttrack फिल्टर मार्गाचा उर्वरित भाग टाळतो, आणि fasttrack केलेले मर्यादित सत्र अजिबात मर्यादित नसते।

राउटरच्या स्वतःच्या सेवा पोहोचू नयेत अशा असाव्यात तर input साखळीसाठी निर्णय पुन्हा करा। पुढे पाठवलेली रहदारी अडवून winbox उघडे ठेवणारी व्याप्ती अर्धीच पूर्ण आहे।

/ip firewall filter
add chain=forward action=jump jump-target=scoped-vpn src-address-list=vpn-scoped-clients
add chain=scoped-vpn action=accept protocol=tcp dst-address-list=vpn-targets dst-port=3389
add chain=scoped-vpn action=drop

काउंटर आणि यादी-सदस्यत्वाने पडताळा

क्लायंटकडून परवानगी दिलेली सेवा आणि अयशस्वी व्हायला हवी अशी सेवा तपासा, मग राउटरवर नियमांची आकडेवारी वाचा। accept आणि drop काउंटर प्रत्येक पॅकेटने कोणता मार्ग घेतला ते दाखवतात, जे क्लायंटला दिसत नाही। जिवंत सत्राचा पत्ता मर्यादित यादीत दिसल्याचीही खात्री करा।

रिकामी यादी म्हणजे खाते दुसऱ्या प्रोफाइलवर आहे किंवा प्रोफाइलने पत्त्यांच्या यादीची सेटिंग गमावली आहे। परवानगी दिलेली सेवा अयशस्वी होत असताना वाढणारा drop काउंटर म्हणजे गंतव्य किंवा पोर्ट क्लायंट पाठवत असलेल्याशी जुळत नाही।

कोणताही निष्कर्ष काढण्यापूर्वी तीच सेवा नावाने आणि पत्त्याने तपासा। नाव विश्लेषणाचा अपयश क्लायंटच्या बाजूने अडवलेल्या पोर्टसारखेच दिसते। मग प्रोफाइल, दोन्ही याद्या आणि एकमेव परवानगी दिलेली सेवा प्रवेश विनंतीत नोंदवा, जेणेकरून पुढील पुनरावलोकन पुन्हा बांधण्याऐवजी तुलना करेल।

/ip firewall filter print stats where chain=scoped-vpn
/ip firewall address-list print where list=vpn-scoped-clients