VPN ફેરફાર પછી રાઉટરનું એડમિન કેમ જવાબ આપવાનું બંધ કરે છે

તમે રાઉટર પર ટનલ ચકાસવા માટે માર્ગ કે ફાયરવોલ નિયમ બદલ્યો, અને હવે એ લેપટોપથી એડમિન પૃષ્ઠ જવાબ આપતું નથી જે દસ મિનિટ પહેલાં બરાબર ચાલતું હતું. સહજ પ્રતિક્રિયા VPN ને દોષ આપવાની છે. મોટા ભાગે ટનલ સ્વસ્થ હોય છે અને બીજી ત્રણમાંથી એક વસ્તુ તૂટે છે: રાઉટરના પોતાના સરનામા તરફ પાછો માર્ગ નથી, કોઈ ઇનપુટ નીતિ વિનંતી ફેંકી દે છે, અથવા કોઈ વેબ સેવા જે સરનામે તમે કૉલ કરો છો ત્યાં સાંભળતી નથી. ત્રણેય બ્રાઉઝરમાં એકસરખા દેખાય છે, એટલે લોકો કલાક સુધી ટનલ ફરી શરૂ કરે છે અને કંઈ શીખતા નથી.

અહીં એ દંતકથા છે જેને પહેલાં મારવી યોગ્ય છે: કામ કરતી ટનલ અંદર પાછા જવાનો રસ્તો નથી. તે પોતાના ભરોસાના પ્રશ્નો સાથેનું નવું નેટવર્ક જોડાણ છે, અને તે તમારો જૂનો એડમિન માર્ગ ચૂપચાપ દૂર કરી શકે છે જ્યારે કોઈએ સમીક્ષા ન કરેલો નવો માર્ગ ખોલે છે.

ટનલ ક્યારેય એડમિન માર્ગ નહોતી

ફોરવર્ડિંગ અને ઇનપુટ અલગ કામ છે. "શું ક્લાયંટ ટનલ દ્વારા NAS સુધી પહોંચી શકે?" એ રાઉટરમાંથી પસાર થતા પેકેટો વિશે ફોરવર્ડિંગ પ્રશ્ન છે. "શું હું રાઉટરનું SSH પોર્ટ ખોલી શકું?" એ રાઉટરને પોતાને સંબોધિત પેકેટો વિશે ઇનપુટ પ્રશ્ન છે. ફોરવર્ડ કરેલા ટ્રાફિક માટે લખાયેલો પાસ નિયમ બીજા પ્રશ્ન માટે કંઈ કરતો નથી, અને એ જ સૌથી સામાન્ય કારણ છે કે ટ્રાફિક સંપૂર્ણ વહન કરતી ટનલ પણ તમારા એડમિન સત્રને નકારે છે.

ઊલટી ભૂલ ઇન્ટરફેસના નામ પર ભરોસો કરવાની છે. ટનલ સાથી સાથે એન્ક્રિપ્ટ થાય છે, તેની પાછળની દરેક સેવા સાથે નહીં, અને ઇન્ટરફેસ લેબલમાંનો VPN શબ્દ એ વિશે કંઈ કહેતો નથી કે કયા સ્રોતોને લોગ ઇન કરવાની મંજૂરી હોવી જોઈએ.

પ્રથમ સ્તર: રાઉટરના પોતાના સરનામા તરફ કોઈ માર્ગ છે?

ક્લાયંટ પરથી શરૂ કરો અને કર્નલને પૂછો કે પેકેટ ક્યાં જશે. Linux પર ip route get 10.6.0.1 પસંદ કરેલો માર્ગ, બહાર જતું ઇન્ટરફેસ અને સ્રોત સરનામું છાપે છે. જો તે તમારા ISP તરફનો ડિફૉલ્ટ માર્ગ બતાવે, તો પેકેટ ક્યારેય ટનલમાં પ્રવેશતું નથી, અને રાઉટર પરનો કોઈ નિયમ તેને બચાવી શકતો નથી.

ટનલની બાજુ પાસે પ્રશ્નનું પોતાનું સંસ્કરણ છે. WireGuard AllowedIPs ને ક્રિપ્ટોકી રૂટિંગ કોષ્ટક તરીકે ગણે છે: દરેક છેડે તે જાહેર કરે છે કે સાથી કયા સ્રોત સરનામાં વાપરી શકે અને કયા લક્ષ્યો તે સાથીને મોકલાય છે. જો ક્લાયંટની નોંધમાં રાઉટરનું ટનલ સરનામું ન હોય, તો ક્લાયંટ પાસે ત્યાં જવાનો માર્ગ નથી. જો તે ક્લાયંટ માટે સર્વરની નોંધ ક્લાયંટનું ટનલ સરનામું આવરી લેતી ન હોય, તો સર્વર કોઈપણ ફાયરવોલ નિયમ જોતાં પહેલાં પેકેટ ફેંકી દે છે.

નીતિ ડિબગ કરતાં પહેલાં તમે પહોંચવા માંગતા ચોક્કસ સરનામાની ખાતરી કરો. જૂની DNS નોંધ કે ફેરફાર પહેલાંની કેશ થયેલી પડોશી નોંધ તમને એવા સરનામે મોકલે છે જે રાઉટર પાસે ક્યારેય નહોતું.

બીજું સ્તર: ઇનપુટ નીતિ, ફોરવર્ડિંગ નીતિ નહીં

ફાયરવોલ પેકેટ જે ઇન્ટરફેસ પર આવે ત્યાં નિયમોનું મૂલ્યાંકન કરે છે. pfSense અને OPNsense માં ઇન્ટરફેસ ટૅબ અને નિયમોનો ક્રમ નક્કી કરે છે કે ફાયરવોલની પોતાની સેવાઓ તરફનો ટ્રાફિક મંજૂર છે કે નહીં; LAN ક્લાયંટને ઇન્ટરનેટ પર જવા દેતો નિયમ એ નિયમ નથી જે ટનલ સાથીને વેબ GUI ખોલવા દે. firewall4 સાથેના OpenWrt માં દરેક ઝોન ઇનપુટ નીતિ ધરાવે છે, option input 'ACCEPT' અથવા 'REJECT', અને ઇનપુટ REJECT હોય તેવા ઝોનમાંનું ટનલ ઇન્ટરફેસ એડમિન જોડાણો નકારશે જ્યારે ફોરવર્ડિંગ મંજૂર હોય તો ટ્રાફિક હજી ફોરવર્ડ કરશે.

નવો માર્ગ કામ કરે તે માટે એન્ટી-લૉકઆઉટ નિયમ બંધ ન કરો. એ નિયમ LAN એડમિન સરનામાને ખરાબ નિયમ દ્વારા લૉક થવાથી બચાવે છે; તે LAN સબનેટનું રક્ષણ કરે છે, તમે હમણાં બનાવેલા ટનલ સબનેટનું નહીં. એડમિનિસ્ટ્રેટરના સ્રોત માટે એક સાંકડો નિયમ ઉમેરો અને સલામતી જાળને અકબંધ રાખો. pfSense નું એડમિન ઍક્સેસ દસ્તાવેજીકરણ સમજાવે છે કે એ નિયંત્રણો ક્યાં છે.

# on the router: bind addresses and the loaded ruleset
ss -ltnp | grep -E ':(22|80|443)\b'         # Linux / OpenWrt
sockstat -4 -l | grep -E ':(22|80|443)\b'   # FreeBSD / pfSense
nft list ruleset | grep -A6 'chain input'    # firewall4
pfctl -sr | head -40                         # pf / pfSense

ત્રીજું સ્તર: તે સરનામે કંઈ સાંભળે છે?

સેવા ચાલુ હોઈ શકે અને તોપણ પહોંચી ન શકાય, કારણ કે તે એક જ સરનામે બંધાઈ છે. OpenWrt નું uhttpd /etc/config/uhttpd માં સ્પષ્ટ શ્રવણ નોંધો રાખે છે, ઉદાહરણ તરીકે list listen_http '0.0.0.0:80'; જે બિલ્ડ ફક્ત LAN સરનામે બંધાય છે તે ટનલ સરનામે કંઈ સ્વીકારતું નથી, અને શ્રવણ-ઇન્ટરફેસ સેટિંગ દર્શાવતા ઉત્પાદનો પણ એ જ રીતે વર્તે છે. ઉપરના શ્રવણ આદેશો આનો સીધો જવાબ આપે છે.

પછી નકારને મૌનથી અલગ કરો. nc -vz 10.6.0.1 443 નકારેલું જોડાણ પાછું આપે એટલે પેકેટ રાઉટર સુધી પહોંચ્યું અને કંઈકે તેને નકાર્યું, કાં બંધ પોર્ટ કાં સ્પષ્ટ નકાર નિયમ. ટાઇમઆઉટ સુધી અટકી રહેવું એટલે પેકેટ ફેંકાયું કે ક્યારેય રૂટ થયું નહીં. એ તફાવત કહે છે કે આગળ કયું સ્તર તપાસવું, અને તેમાં પાંચ સેકન્ડ જાય છે.

VPN ઇન્ટરફેસ એ સીમા છે, પુનઃપ્રાપ્તિ માર્ગ નહીં

એન્ક્રિપ્શન વાયરને રક્ષે છે; એડમિન પૃષ્ઠ કોણ ખોલી શકે એ વિશે તે કંઈ કહેતું નથી. ટનલ કામ કરવા લાગે પછી, ટનલ ઇન્ટરફેસ પર બધું મંજૂર કરીને પહોંચની સમસ્યા ઉકેલવાની લાલચનો પ્રતિકાર કરો. એડમિનિસ્ટ્રેટરને તેમના પોતાના ટનલ સરનામે જોડાયેલો નિયમ કે અલગ ફક્ત-એડમિન ટનલ આપો, અને સામાન્ય વપરાશકર્તાઓ, NAS, કૅમેરા અને પરિવારના લેપટોપને એડમિન પોર્ટથી દૂર રાખો. ફાઇલ શેરિંગ જોઈતા સાથીને રાઉટરના લોગિનથી એક નિયમના અંતરે પણ ન હોવું જોઈએ.

રાઉટરની ભૂમિકા જવાબ બદલે છે. જે રાઉટર ટનલનું સમાપન કરે છે તે તેમાંથી એડમિનિસ્ટ્રેટરને કાયદેસર સ્વીકારી શકે છે, જ્યારે ટનલને ફક્ત ઇન્ટરનેટ એક્ઝિટ તરીકે વાપરતું રાઉટર સામાન્ય રીતે એમ ન કરવું જોઈએ. બંને કિસ્સામાં સબનેટ પરવાનગી એ લોગિન નથી, તેથી ખાતા પ્રમાણીકરણ અને પરિવહન સુરક્ષા ચાલુ રાખો.

લૉકઆઉટ પછી લોકો જે વળતરપૂરક પગલું લે છે તે વધુ ખરાબ છે: WAN એડમિનિસ્ટ્રેશન ચાલુ કરવું કે વેબ GUI તરફ પોર્ટ ફોરવર્ડ કરવું. તે ટૂંકા વિક્ષેપને કાયમી છાવણીમાં ફેરવે છે, અને લોગિન પૃષ્ઠ પછી ઇન્ટરનેટના દરેક સ્કેનર માટે પહોંચી શકાય તેવું બને છે. મંજૂર બાજુની જેમ નકારેલી બાજુ પણ ચકાસો, જેથી એડમિન ઍક્સેસ ન હોવો જોઈએ તેવા સાથીને લોગિન પ્રોમ્પ્ટ મળવાને બદલે ટાઇમઆઉટ કે નકાર મળે.

નવા જોડાણ સાથે પણ ચકાસો. સ્ટેટફુલ ફાયરવોલ હાલના ફ્લોને પોતાના સ્ટેટ કોષ્ટકમાં રાખે છે, તેથી તમારું પહેલેથી ખુલ્લું SSH સત્ર દરેક નવા જોડાણને અવરોધતા ફેરફારમાંથી પસાર થઈ શકે છે. એ રીતે લૉકઆઉટ આગલા રીબૂટ કે લેપટોપની આગલી ઊંઘ સુધી અદૃશ્ય રહે છે.

નીતિને અડકતાં પહેલાં પાછા જવાનો રસ્તો તૈયાર કરો

પહેલા ફેરફાર પહેલાં ચાર વસ્તુઓ લખો: ટનલ મરી જાય તો તમે ઉપકરણ સુધી કેવી રીતે પહોંચશો, જેમ કે સીરિયલ કન્સોલ, પ્રદાતાનું કન્સોલ કે LAN પરનું મશીન; હાલનું રૂપરેખાંકન ક્યાં નિકાસ થાય છે; તમે કયો એક નિયમ કે માર્ગ બદલવાના છો; અને એ જ વસ્તુને તમે કેવી રીતે પાછી લાવશો. OpenWrt પર sysupgrade -b /tmp/backup.tar.gz રૂપરેખાંકન પકડે છે, અને ફેરફારો uci commit સુધી બાકી રહે છે, જે સમયસર ધ્યાન આવે તો સસ્તું પૂર્વવત્ કરવાનું આપે છે. pfSense રૂપરેખાંકન ઇતિહાસ રાખે છે, અને AutoConfigBackup ફક્ત ત્યારે મદદ કરે છે જ્યારે તે પહેલેથી ચાલુ હોય. રાઉટર fail-closed નિયમસમૂહ ચલાવતું હોય, તો ખાતરી કરો કે તમે આયોજિત જાળવણી માર્ગ એ નિયમ જે ટ્રાફિકને અવરોધે છે તેની અંદર નથી, અને યાદ રાખો કે રીબૂટ સ્થાયી નિયમોને ભૂંસવાને બદલે ફરી લાગુ કરે છે.

દરેક પ્રયાસે એક સીમા બદલો, પછી ખુલ્લું રાખેલા શેલને બદલે નવા જોડાણથી ચકાસો. પરીક્ષણ નિષ્ફળ જાય તો આગલા સ્તરને અડકતાં પહેલાં એ એક ફેરફાર પાછો ખેંચો. ટનલ આખો સમય ઉપર રહી શકે છે, પણ તેનું લીલું સ્થિતિ ચિહ્ન એ પુરાવો નથી કે તમે હજી અંદર જઈ શકો છો.

જતાં પહેલાં ઝડપી તપાસ:

• તમે હમણાં સંપાદિત કરેલા નિયમ પર આધાર ન રાખતા સ્રોતથી રાઉટર સુધી પહોંચી શકો છો?
• ટનલ ઇન્ટરફેસ પરની ઇનપુટ નીતિ ફક્ત એડમિનિસ્ટ્રેટરના સ્રોતને મંજૂર કરે છે?
• એડમિન સેવા ટનલ પર હયાત એવા સરનામે બંધાયેલી છે?
• તમે એક નકારેલો સાથી અને એક નવું સત્ર ચકાસ્યું છે?
• WAN એડમિન સપાટી હજી બંધ છે?