तुमचा LAN VPN क्लायंटवरील सेवेपर्यंत का पोहोचू शकत नाही

VPN क्लायंट अशी सेवा होस्ट करू शकतो जी LAN उघडू शकत नाही. सहसा जे कमी असते ते म्हणजे परतीचा मार्ग: एक रूट, एक DNAT जोडी, किंवा जी SNAT ओळ कोणीही जोडत नाही.

तुमचा टनेल सुरू आहे, सेवा ऐकत आहे, आणि कार्यालयाच्या LANला अजूनही काहीच परत मिळत नाही। कोणीही VPN तोडले नाही। LANच्या बाजूने, लॅपटॉपचा टनेल पत्ता तोपर्यंत अस्तित्वात नाही जोपर्यंत काहीतरी LANला तिथे कसे पोहोचायचे ते सांगत नाही, आणि विनंती ज्या मार्गाने बाहेर गेली त्याच मार्गाने उत्तर परत यायला हवे। कोणी परतीच्या मार्गाकडे पाहण्यापूर्वी लोकांनी पूर्णपणे निरोगी टनेल तीन वेळा पुन्हा बांधताना मी पाहिले आहे।

तुटलेला टनेल नाही

दोन्ही टोके खाजगी श्रेणींवर बसतात, ही सामान्य स्थिती आहे आणि चुकीची रचना नाही। 10.8.0.6 सारखा पत्ता टनेलच्या आत खरा आहे आणि इतर कुठेही नाही, म्हणून LANला तिथे काही पाठवण्याचे कारण नाही। राउटिंगला हात लावण्यापूर्वी सेवा टनेलच्या आत अजिबात पोहोचण्यायोग्य आहे का याची खात्री करा: क्लायंटवर ss -ltn दाखवते की श्रोता 127.0.0.1, LAN इंटरफेस किंवा टनेल पत्त्याशी जोडलेला आहे का। फक्त loopback ला जोडलेला डेमन स्वतःशिवाय कोणालाही उत्तर देत नाही, आणि कोणताही रूट, DNAT किंवा पोर्ट फॉरवर्डिंग ते बदलत नाही।

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

रूटचा आकार: LANला सांगा की तलाव कुठे आहे

LAN गेटवेवरील स्थिर रूट सर्वात स्वच्छ उत्तर आहे जेव्हा LAN आणि टनेलचा तलाव एकमेकांवर येत नाहीत। तलाव टनेल संपवणाऱ्या मशीनकडे वळवा:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

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

push "route 192.168.1.0 255.255.255.0"

सर्व्हरच्या मागे नाही तर एका क्लायंटच्या मागे असलेल्या सबनेटसाठी, सर्व्हरला सिस्टम रूट आणि त्या क्लायंटच्या फाइलमध्ये iroute नोंद दोन्ही हवी, जी client-config-dir अंतर्गत असते। iroute शिवाय, OpenVPN ला उपसर्ग अस्तित्वात असल्याचे माहीत आहे आणि कोणता क्लायंट त्याचा मालक आहे हे माहीत नाही: पॅकेट येतात आणि डेमनकडे त्यांना जुळवण्यासाठी काहीच नसते।

इथे नाव देण्यासारखी एक मिथक आहे। रूट पत्ता पोहोचण्यायोग्य बनवते; ते समोरच्या बाजूला उत्तर देण्यास तयार करत नाही। साइट-ते-साइट सहकारी वर आणखी एक थर जोडतात, कारण दूरचा गेटवे फक्त त्याच्या धोरणात सूचीबद्ध उपसर्गांच्या आतल्या स्रोतांना स्वीकारतो, आणि घरच्या तलावातून येणारा लॅपटॉप त्यांच्या आत नसतो।

NATचा आकार: आत DNAT, आणि सर्वजण वगळणारी SNAT ओळ

जेव्हा तुम्ही LAN गेटवेला हात लावू शकत नाही, किंवा नेमका एक पोर्ट प्रकाशित करू इच्छिता, VPN होस्टवरील भाषांतर LANवर कोणत्याही रूटशिवाय चालते। पोर्ट प्रकाशित करा, फॉरवर्ड करा, आणि टनेलमध्ये जाण्याच्या मार्गावर स्रोताचे भाषांतर करा:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

तिसरी ओळ हीच हरवणारी ओळ आहे। ती वगळा आणि क्लायंट मूळ LAN पत्ता स्रोत म्हणून पाहतो, स्वतःच्या डीफॉल्ट रूटने उत्तर देतो, आणि ते उत्तर LANकडे परत जाण्याऐवजी टनेलमध्ये जाते। कनेक्शन टिकेल का हे तुम्ही कधीच नियोजित न केलेल्या राउटिंगवर अवलंबून असते। SNAT सह क्लायंट सर्व्हरचा टनेल पत्ता पाहतो, म्हणून उत्तर टनेलमधून परत भाषांतर रद्द करू शकणाऱ्या एकमेव होस्टपर्यंत जाते।

ग्राहक फर्मवेअर स्वतःची साखळी नावे वापरते आणि तुमच्यासाठी ते भाषांतर तयार करत नाही। Tomato वर, इनबाउंड नियम WANPREROUTING मध्ये पडतो आणि नंतर wanin सारख्या फिल्टर साखळीत, आणि पूर्ण दिसणाऱ्या नियम संचालाही अजूनही हाताने लिहिलेली POSTROUTING ओळ लागते। ती फर्मवेअरची गुंतागुंत नाही; तो फक्त इनबाउंड रहदारीसाठी लिहिलेला नियम संच आहे।

बरोबर दिसणारा नियम तरीही पॅकेट का टाकतो

यापैकी बहुतेक अपयश तुम्ही पाहत असलेल्या नियमात नसते। या क्रमाने चार गोष्टी तपासा, आणि जी पहिली जुळत नाही तिथे थांबा:

  • साखळ्यांचा क्रम। iptables -I वर घालतो आणि -A शेवटी जोडतो, म्हणून आधीचा परवानगी देणारा किंवा अडवणारा नियम आधी ठरवतो।
  • चुकीची साखळी। राउटरलाच उद्देशलेली रहदारी INPUT मधून जाते, आणि फॉरवर्ड केलेली रहदारी तिला कधीच स्पर्श करत नाही। एक सेवा प्रकाशित करण्यासाठी दोन्हीत नियम लागू शकतात।
  • दिशा फ्लॅग। -i tun0 क्लायंटकडून येणाऱ्या रहदारीशी जुळतो आणि -o tun0 त्यांच्याकडे जाणाऱ्या रहदारीशी। चुकीच्या फ्लॅगसह REJECT तुम्हाला नको असलेले काहीतरी अडवते।
  • स्रोत मर्यादा। एक क्लायंट पत्ता स्वीकारणारे फॉरवर्डिंग त्या क्लायंटपासून चालते आणि प्रत्येक इतर स्रोत एक शब्दही न बोलता टाकून देते।

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

स्थानिक फॉरवर्डिंग, जेव्हा LANवर काहीच बदलता येत नाही

SSH स्थानिक फॉरवर्डिंग संपूर्ण प्रश्न बाजूला करते। त्याला LANवर रूट, क्लायंटच्या फायरवॉलचे सहकार्य, आणि कुठेही प्रकाशित पोर्ट लागत नाही:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

मग सेवा टनेल धरून ठेवणाऱ्या मशीनच्या localhost:3000 वर दिसते, आणि इतर कुठेही नाही। हीच मर्यादा आहे: एक वर्कस्टेशन, एक पोर्ट, आणि काहीतरी ते पुन्हा सुरू केल्याशिवाय फॉरवर्डिंग सत्रासोबत मरते। स्टेजिंग डेटाबेस तपासणाऱ्या प्रशासकासाठी हे योग्य साधन आहे। इतर लोकांना पोहोचायचे असलेल्या कॅमेरा किंवा स्कॅनरसाठी ते नाही, कारण प्रत्येक वापरकर्त्याला स्वतःचे फॉरवर्डिंग लागेल।

आणखी एक नियम जोडण्यापूर्वी दोन्ही दिशा तपासा

भाषांतर खुणा सोडते, आणि त्या वाचणे अंदाज लावण्यापेक्षा चांगले आहे। VPN होस्टवर, conntrack -L भाषांतर अजिबात झाले का हे दाखवते, iptables -t nat -L -n -v काउंटर हलले का हे दाखवते, आणि tcpdump -ni any port 3000 कोणता स्रोत पत्ता खरोखर आला हे दाखवते। क्लायंटवर, ss -ltn श्रोता टनेल पोहोचू शकणाऱ्या पत्त्यावर असल्याची खात्री देतो।

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

संबंधित लेख