OpenBSD VPN गेटवेवर tun0 मार्फत LAN चे NAT

एकाच OpenBSD गेटवे असलेले दोन अभियंते दूरच्या नेटवर्कपर्यंत पोहोचण्यासाठी तुम्हाला अनेकदा दोन वेगळे नियमसंच देतात, आणि दोन्हीचे समर्थन करता येते। स्रोत भाषांतर आणि परतीचा मार्ग यामधील निवड हा मुळीच वाक्यरचनेचा प्रश्न नाही। ती यावर अवलंबून आहे की समोरच्या बाजूला 192.168.88.0/24 बद्दल आधीच काय माहीत आहे आणि तुम्हाला तुमच्या लॉगमध्ये काय ठेवायचे आहे। इथे चूक झाल्यास nat-to ओळ अगदी बरोबर दिसेल पण उत्तरे दूरच्या डीफॉल्ट गेटवेमध्ये गायब होतील।

राउटिंग आणि पुनर्लेखन वेगवेगळ्या प्रश्नांची उत्तरे देतात

राउटिंग तक्ता ठरवतो की 172.20.0.0/16 tun0 मार्फत पोहोचण्यायोग्य आहे, आणि हा निर्णय कोणत्याही pf भाषांतराचा सल्ला घेण्यापूर्वी घेतला जातो। त्यानंतर स्रोत भाषांतर पॅकेटचे शीर्षक बदलते, जेणेकरून दूरच्या टोकाला LAN होस्टऐवजी गेटवेचा बोगदा पत्ता दिसेल। कोणतेही यंत्रणा दुसऱ्याची जागा घेत नाही: nat नियम मार्ग निर्माण करू शकत नाही, आणि मार्ग तुमच्या खासगी उपजाळाबद्दल कधीही न ऐकलेल्या दूरच्या राउटरला पटवू शकत नाही। समोरच्या बाजूला परतीचा मार्ग नसल्यास उत्तरे टाकून दिली जातात किंवा त्याच्या डीफॉल्ट गेटवेकडे पाठवली जातात, आणि नियम कितीही सुधारले तरी ते बरोबर होत नाही।

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

ठरवणाऱ्या तीन अटी

तीन प्रश्न क्रमाने विचारा आणि रचना बहुतेकदा स्वतःच निवडली जाते। दूरच्या नेटवर्ककडे 192.168.88.0/24 साठी बोगदा पत्त्याकडे निर्देश करणारा स्थिर मार्ग आहे का, किंवा त्याचा प्रशासक त्या मार्गावरील राउटर नियंत्रित करतो का? होय असल्यास LAN पत्ते बदल न करता जाऊ द्या आणि भाषांतर पूर्णपणे वगळा। समोरच्या बाजूला प्रत्येक क्लायंटची दृश्यमानता हवी आहे का, प्रवेश धोरणासाठी किंवा लेखापरीक्षणाच्या नोंदीसाठी? होय असल्यास स्रोत जपणे राउटिंगच्या कामाला योग्य आहे। बोगदा पत्ता दूरच्या मार्गात लिहिण्याइतका स्थिर आहे का, की पुनर्जोडण्यांदरम्यान बदलतो?

कोणतेही उत्तर नाही किंवा अज्ञात असल्यास nat-to हा व्यवहार्य पर्याय आहे, आणि तो उलटवताही येतो। समोरची बाजू योग्य मार्ग जोडताच भाषांतराचा नियम एका ओळीत निघून जातो। कधीही स्थापित न केलेला परतीचा मार्ग, बोगदा फक्त एकाच दिशेने का चालतो असे कोणी विचारल्यावर प्रत्येक वेळी एक समर्थन धागा खातो।

pf प्रत्यक्षात मूल्यमापन करेल अशा जागी तुकडा ठेवा

खालील तुकडा गृहीत धरतो की LAN 192.168.88.0/24 आहे, दूरचे नेटवर्क 172.20.0.0/16 आहे आणि बोगदा इंटरफेस tun0 आहे। त्यात पुढील हॉप निवडणारे काहीही नाही। तो फक्त आधीच बोगद्यातून बाहेर जाणाऱ्या पॅकेटवरील स्रोत पुन्हा लिहितो।

match out on tun0 inet from 192.168.88.0/24 to 172.20.0.0/16 nat-to (tun0)
pass in on em0 inet from 192.168.88.0/24 to any keep state

त्या पहिल्या ओळीतील दोन तपशील सर्वाधिक भार उचलतात। tun0 भोवतीचे कंस pf ला सांगतात की स्थिती नोंद तयार करताना प्रत्येक वेळी इंटरफेसचा पत्ता वाचावा, जे पुनर्जोडणीनंतर बोगद्याचे पुनर्क्रमांकन झाल्यावर महत्त्वाचे ठरते। match या शब्दाचा अर्थ नियम पुन्हा लिहितो आणि नंतर खाली पडतो असा आहे, त्यामुळे वेगळ्या pass नियमानेही प्रवाहाला परवानगी द्यावी लागते। match ओळीत नामनिर्देशित इंटरफेसही राउटिंग तक्ता निवडतो तोच असावा, अन्यथा pf नियमाचे मूल्यमापन पॅकेट प्रत्यक्षात जात असलेल्या मार्गापेक्षा वेगळ्या बाहेर जाणाऱ्या मार्गावर करेल।

कर्नेलची बाजू विसरू नका। IPv4 फॉरवर्डिंग सक्षम असणे आवश्यक आहे, आणि बोगदा व LAN साठी स्थितीयुक्त pass नियम या सर्वांचा अर्थ होण्यापूर्वी असणे आवश्यक आहे। येथे कीवर्डच्या क्रमासाठी OpenBSD FAQ मधील PF NAT विभाग योग्य संदर्भ आहे।

रहदारीवर विश्वास ठेवण्यापूर्वी नियमसंच तपासा

प्रथम pfctl -nf /etc/pf.conf ने वाक्यरचना तपासा, जे फाइल न लोड करता विश्लेषण करते। त्यानंतर धोरण लोड करा आणि कर्नेल प्रत्यक्षात काय धरून ठेवते ते वाचा, कारण स्वच्छ विश्लेषण झालेला नियमही सावलीत राहू शकतो किंवा चुकीच्या इंटरफेसला जोडला जाऊ शकतो। pfctl -sn भाषांतर नियम त्यांच्या लोड झालेल्या स्वरूपात छापते, आणि pfctl -sr फिल्टर नियम मूल्यमापन क्रमाने छापते।

पुढे तारेवर लक्ष ठेवा। गेटवेवर tcpdump -ni tun0 'host 172.20.0.10' दाखवते की बोगद्यातून बाहेर पडणारा स्रोत पत्ता बोगद्याचा पत्ता आहे की LAN होस्ट। झटपट netstat -rn -f inet गंतव्य कोणत्या इंटरफेसवर सोडवले जाते याची खात्री देते। रहदारी वाहू लागताच pfctl -ss स्थिती नोंदी सूचीबद्ध करते; जर प्रवाहाने स्थिती तयार केली नाही, तर पॅकेट कधीही स्थिती तयार करणाऱ्या नियमाला लागले नाही।

बोगद्याची बाजू बरोबर दिसत असूनही उत्तरे येत नसल्यास pf संपादित करणे थांबवा। उर्वरित बिघाड दूरच्या राउटरवर आहे, जिथे उत्तर त्या बाजूला पोहोचू न शकणाऱ्या खासगी पत्त्याकडे पाठवले जात आहे।

जेव्हा भाषांतर बचतीपेक्षा जास्त खर्च करते

भाषांतर क्लायंट लपवते, आणि कधीकधी तोच चुकीचा व्यवहार असतो। एकमेकांवर येणारी उपजाळे ही एक स्थिती: समोरची बाजू आतूनही 192.168.88.0/24 वापरत असल्यास, LAN होस्टना गेटवे म्हणून दाखवणे टक्कर सुधारण्याऐवजी बिघडवते। पत्ता जोडीने रहदारी निवडणारी IPsec धोरणे ही दुसरी स्थिती, कारण सुरक्षा धोरण डेटाबेस भाषांतरापूर्वी जुळवला जातो आणि तुमचे पुनर्लिखित पॅकेट कधीही पाहत नाही। प्रत्येक वापरकर्त्यासाठी बिल करणारी, मर्यादित करणारी किंवा लेखापरीक्षण करणारी कोणतीही तैनातीही स्रोत एका पत्त्यावर संकुचित होण्याच्या क्षणी आवश्यक असलेली ओळख गमावते।

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

खऱ्या नेटवर्कशी संपर्कात टिकणारा निर्णय नियम लहान आहे: जेव्हा शक्य असेल तेव्हा परतीचा मार्ग स्थापित करा, जेव्हा शक्य नसेल तेव्हा भाषांतर करा, आणि तीनपैकी कोणत्या अटीने तुम्हाला ती निवड करायला लावली ते लिहून ठेवा। ती नोंद पुढच्या व्यक्तीची पूर्ण दुपार वाचवते।