राउटर VPN नियम: स्रोत आणि गंतव्य जुळवा
राउटरवरील VPN नियमाला दोन टोके असतात: ट्रॅफिक पाठवणारे उपकरण आणि टनल वापरायचे गंतव्य। आधी छेदन आणि फॉलबॅक ठरवा।
राउटर खरेदीची पाने VPN राउटिंग एक चेकबॉक्स म्हणून दाखवतात, आणि हे वाक्य तीन वेगळे प्रश्न लपवते। नियम ट्रॅफिक पाठवणाऱ्या उपकरणाशी जुळतो का, ते स्वीकारणाऱ्या सर्व्हरशी जुळतो का, की दोन्हीशी? कोणाशीही न जुळणाऱ्या ट्रॅफिकचे काय होते? आणि दोन नियम एकमेकांवर आल्यावर कोण जिंकतो? उत्तर स्रोत आणि गंतव्याची जोडी म्हणून लिहिल्यास अस्पष्ट वैशिष्ट्य-यादी चाचणीयोग्य रचनेत बदलते।
वैशिष्ट्याचे नाव दोन टोके लपवते
टनल वापरायचा असलेला मीडिया प्लेअर स्रोत-जुळणी आहे। टनलमधून पोहोचायचा असलेला खाजगी ऑफिस प्रीफिक्स गंतव्य-जुळणी आहे। टनल फक्त एका सेवेसाठी वापरायचे असलेले वर्कस्टेशन दोन्ही आहे, आणि तेच छेदन बहुतेक ग्राहक फर्मवेअर जी गोष्ट वाईटपणे हाताळते आहे।
उत्पादनांची तुलना करण्यापूर्वी गरज जोडी म्हणून लिहा। तीच जोडी तुम्ही नंतर तपासाल।
उपकरण-यादी किंवा जागतिक गंतव्य-यादी देणारे उत्पादन «फक्त हे उपकरण, फक्त ही गंतव्ये» व्यक्त करू शकत नाही असे होऊ शकते। हे अंतर दिखाऊ नाही: जागतिक गंतव्य-नियम त्या साइटसाठी प्रत्येक उपकरणाचा ट्रॅफिक टनलमधून पाठवतो, आणि उपकरण-नियम त्या उपकरणाचा सर्व ट्रॅफिक पाठवतो। दोन्हीपैकी कोणतीही गरज नाही। स्क्रीनवर विश्वास ठेवण्यापूर्वी ती स्थिती दोन उपकरणांसह तपासा।
नियम छेदन म्हणून बांधा
तक्ता रचना प्रामाणिक ठेवतो। परिस्थिती डावीकडे ठेवा, नंतर पाठवणाऱ्याची जुळणी आणि लक्ष्याची जुळणी वेगळी नाव द्या:
| Scenario | Sender match | Target match | Rule shape |
|---|---|---|---|
| Media player uses the tunnel | Player address | Any internet destination except the LAN | Source only |
| Office prefix reachable | Authorized LAN devices | 10.40.0.0/16 | Target only |
| One app on one laptop | Laptop address | The service address set | Source and target |
| Guest network never tunnels | Guest subnet | Any | Deny, evaluated first |
तिसरी ओळ मनोरंजक आहे, कारण तिला दोन्ही अर्धे एकाच वेळी हवे आहेत। फर्मवेअर फक्त एक अक्ष व्यक्त करू शकत असेल, तर गरज दोन नियमांत विभागावी किंवा ते करू शकणाऱ्या उपकरणात हलवावी।
स्रोताची ओळख स्थिर ठेवा। DHCP आरक्षण, समर्पित सेगमेंट किंवा उपकरण-ओळख यंत्रणा सर्व काम करतात, पण लीज संपल्यानंतर बदलणारा पत्ता करत नाही। IPv6 समाविष्ट करा, कारण एक IPv4 पत्ता उपकरणाचा सर्व ट्रॅफिक ओळखत नाही।
ओव्हरलॅप प्राधान्य ठरवते
नियमांचा ओव्हरलॅप सामान्य आहे। रुंद उपकरण-नियम आणि अरुंद गंतव्य-नियम दोन्ही एकच प्रवाह वर्णन करू शकतात, आणि दस्तऐवजीकृत प्राधान्यक्रम कोण जिंकेल ते ठरवतो। आकर्षक सेटिंग्ज स्क्रीन तुम्हाला तो क्रम सांगत नाही।
क्रम आणि जुळणी नसलेल्या स्थितीसाठी पुस्तिका वाचा, नंतर तुम्ही पाहू शकता अशा ट्रॅफिकसह दोन्ही तपासा:
ip rule show
ip route get 203.0.113.10दस्तऐवजांत क्रम नसेल, तर अरुंद नियम जिंकणार नाही असे गृहीत धरा आणि त्यानुसार रचना करा। जे दोन नियम परस्परविरोधी होऊ शकत नाहीत त्यांना आधार देणे, प्राधान्य अलिखित असलेल्या एका हुशार नियमापेक्षा सोपे आहे।
नावांना रीफ्रेश धोरण हवे
डोमेन म्हणून लिहिलेले गंतव्य देखभालीची समस्या जोडते। राउटरला ते सोडवावे लागते, मॅपिंग रीफ्रेश करावे लागते, अनेक पत्ते आणि उपडोमेन हाताळावे लागतात, आणि अपेक्षित रिझॉल्व्हरला टाळणाऱ्या अनुप्रयोग DNS ला तोंड द्यावे लागते।
एक शोधनिकाल IP नियमात कॉपी करणे स्नॅपशॉट आहे, डोमेन धोरण नाही।
नियम चुकण्यापूर्वी उत्तर किती जुने असू शकते, आणि रिझोल्यूशन अयशस्वी झाल्यावर राउटर काय करतो ते ठरवा। शेवटचा ज्ञात पत्ता ठेवणारा नियम सेवा-स्थलांतरानंतर टिकू शकतो; नोंद टाकून देणारा नियम टनलिंग गुपचूप थांबवू शकतो। दोन्ही वर्तन स्वीकार्य आहेत, जर ती नियमाच्या शेजारी लिहिलेली असतील।
अनुपलब्ध स्थिती परिभाषित करा
मार्ग प्राधान्य फक्त-VPN ट्रॅफिक लादत नाही। टनल बंद असताना, राउटर प्रवाह अडवू शकतो, थेट पाठवू शकतो किंवा दुसरी टनल वापरू शकतो, आणि प्रत्येक निवडीची अयशस्वी ओळख वेगळी असते।
गरजेला कोणती हवी आहे ते ठरवा, नंतर टनल थांबवून आणि प्रवाह पाहून ते तपासा:
curl -sS -o /dev/null -w "%{http_code}" --max-time 5 https://service.example/
ping -c 2 203.0.113.10राउटरमधूनच निर्माण होणारा ट्रॅफिक वेगळे क्षेत्र आहे। DNS फॉरवर्डिंग, अद्ययावत तपासण्या आणि देखरेख उपकरणाची स्रोत-जुळणी वारसा न घेता राउटरमधूनच नवे प्रवाह सुरू करू शकतात। त्या प्रवाहांचा स्पष्ट विचार करा, नाहीतर ते लॉगमध्ये अस्पष्ट गळती म्हणून दिसतील।