VPN ની બહાર ફક્ત એક સ્થાનિક વેબ સેવાને પોર્ટ પ્રમાણે રૂટ કરો

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

નિયમ લખતાં પહેલાં ત્રણ શરતો તપાસો

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

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

જવાબ મેળવો, ક્લાયન્ટનો ગંતવ્ય પોર્ટ નહીં

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

જવાબની દિશા એ છે જે તમે અલગ કરી શકો છો. સ્રોત પોર્ટ મેળવો, નિયમને સ્થાનિક રીતે ઉત્પન્ન થયેલા પેકેટ સુધી મર્યાદિત કરો, અને નિયમ બ્રાઉઝરની વિનંતીઓને અડ્યા વિના સેવાના પોતાના જવાબોને આવરી લે છે.

નિયમ તે તરફ નિર્દેશ કરે તે પહેલાં સંપૂર્ણ રિટર્ન ટેબલ બનાવો

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

ip -4 route add table 100 192.0.2.0/24 dev eth0
ip -4 route add table 100 default via 192.0.2.1 dev eth0
ip -4 rule add priority 1000 iif lo ipproto tcp sport 443 lookup 100

નંબરો નકલ કરવાને બદલે જીવંત હોસ્ટ પરથી વાંચો. ip -4 rule show તમને કહે છે કે કઈ પ્રાથમિકતાઓ લેવાયેલી છે, અને પહેલેથી હાજર પ્રાથમિકતા પર નિયમ ઉમેરવાથી જાતે સાચા દેખાતા બે નિયમોનો ક્રમ ચૂપચાપ બદલાઈ જાય છે.

અહીં અસલી કામ બે સિલેક્ટર કરે છે. iif lo એ છે કે કર્નલ હોસ્ટે પોતે ઉત્પન્ન કરેલા પેકેટની જાણ કેવી રીતે આપે છે, તેથી નિયમ બહારથી આવતા ફોરવર્ડ ટ્રાફિકને અકસ્માતે પકડી શકતો નથી. ipproto tcp sport 443 તેને એક ટ્રાન્સપોર્ટ અને એક પોર્ટ સુધી સાંકડો કરે છે, જે જરૂરિયાત પરવાનગી આપે તેટલું ચુસ્ત છે. પ્રોટોકોલ સિલેક્ટર કાઢી નાખો તો નિયમ UDP 443 પણ પકડે છે, જે અલગ વર્તન ધરાવતી અલગ સેવા છે.

ખાનગી જવાબો ટનલની અંદર રાખો

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

ip -4 route add table 100 throw 10.90.0.0/24

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

રિવર્સ-પાથ ફિલ્ટરિંગ અને હોસ્ટ ફાયરવોલ નિયમો આવતી વિનંતી પર હજી લાગુ પડે છે. માન્યતા ઢીલી કરતાં પહેલાં તેમના વાસ્તવિક ચુકાદા જુઓ, કારણ કે રૂટિંગ અપવાદ rp_filter ને અશક્ય ગણતો પરત માર્ગ સ્વીકારવા મજબૂર કરતો નથી.

TCP, પછી QUIC, પછી રીબૂટ ચકાસો

અધિકૃત બાહ્ય ક્લાયન્ટથી એક અને ખાનગી બાજુથી એક કનેક્શન ખોલો, પછી વાસ્તવિક સરનામાં અને પોર્ટ સાથે જવાબ-શોધ તપાસો. બાહ્ય જવાબ ટેબલ 100 લે અને ખાનગી જવાબ ન લે, તો નીતિ તમે માંગ્યું તે જ કરી રહી છે.

HTTP/3 UDP પર પરોસાય છે અને TCP નિયમ સાથે મેળ નહીં ખાય, તેથી QUIC લિસનરને પોતાનું સિલેક્ટર જોઈએ, નહીં તો HTTPS ચાલતું હોય ત્યારે પણ તે ટનલ વાપરતું રહેશે. તમે જે નિયમો પર સ્થિર થાઓ તે ઇન્ટરફેસનો માલિક ધરાવતા ઘટકમાં સાચવો, અને ફરી જોડાણ કે DHCP નવીકરણ પછી તેમની ખાતરી કરો. રીબૂટ પછી સ્પર્ધક મેનેજર રનટાઇમ રૂટ દૂર કરે, તો એ મૂળમાં ઠીક કરવાની માલિકીની સમસ્યા છે, ઉપર વધુ વિશાળ NAT નિયમો ઉમેરવાનું કારણ નહીં.