પોર્ટ 80 અને 443 ના નિયમો બ્રાઉઝરને VPN દ્વારા મોકલતા નથી
પોર્ટ મેચ TCP પ્રવાહો પસંદ કરે છે, બ્રાઉઝર નહીં. HTTP/3 UDP પર ચાલે છે, DNS બીજો રસ્તો લઈ શકે છે, અને અપડેટર તમે લખેલા એ જ નિયમ સાથે મેળ ખાય છે.
કોઈ બ્રાઉઝર ટનલ વાપરે એવી વિનંતી કરે છે, અને જવાબ ગંતવ્ય પોર્ટ 80 અને 443 સાથે મેળ ખાતા ફાયરવોલ નિયમ તરીકે પાછો આવે છે. તે સચોટ લાગે છે અને છે નહીં. પોર્ટ મેચ પેકેટને તેમના પરિવહન હેડર પ્રમાણે પસંદ કરે છે, કઈ પ્રોગ્રામે સોકેટ ખોલ્યું તે પ્રમાણે નહીં, અને આધુનિક બ્રાઉઝિંગ TCP પર એ બે પોર્ટ સુધી મર્યાદિત નથી. નિયમ તમે સમાવવા માંગતા હતા તેમાંથી કેટલોક ટ્રાફિક ચૂકી જશે અને તમે ક્યારેય અડવા માંગતા ન હતા તે ટ્રાફિક પકડશે. તે લખતા પહેલાં નક્કી કરો કે ત્રણ જુદી સીમાઓમાંથી તમે ખરેખર કઈ ઈચ્છો છો.
નિયમ પરિવહન વર્ગનું વર્ણન કરે છે, એપ્લિકેશનનું નહીં
Linux માં, ગંતવ્ય-પોર્ટ મેચ TCP હેડર તપાસે છે અને તેની ઉપર કંઈ નહીં. તે પેકેટને ચિહ્નિત કરીને નીતિ-માર્ગ દ્વારા દોરવું દસ્તાવેજીકૃત પ્રમાણે બરાબર કામ કરે છે, અને એ કોઈ પણ યંત્ર નથી જાણતું કે પેલોડનો અર્થ શું છે અથવા કઈ પ્રક્રિયાએ તે મોકલ્યું. ચિહ્ન એ પેકેટ સાથે જોડાયેલી સંખ્યા છે, એપ્લિકેશન સાથે જોડાયેલી ઓળખ નહીં.
nft add rule inet mangle output tcp dport { 80, 443 } meta mark set 0x1
ip rule add fwmark 0x1 table 100
ip route add default dev wg0 table 100તરત જ બે પરિણામ આવે છે. TCP 443 સાથે સંપર્ક કરતું સોફ્ટવેર અપડેટર બ્રાઉઝર જેવું જ વર્તન મેળવે છે, જે ઠીક હોઈ શકે અથવા આગલી અપડેટ ચક્રની રાહ જોતું વિક્ષેપ હોઈ શકે. અને જાણી જોઈને બીજા પોર્ટ પર પ્રકાશિત થયેલી વેબ સેવા, કહો 8443, નિયમની સંપૂર્ણ બહાર રહે છે, જ્યારે તે હજુ પણ એ જ વેબ ટ્રાફિક છે જેની વપરાશકર્તાને ચિંતા હતી.
જ્યારે જરૂરિયાત ખરેખર એ પોર્ટની હોય ત્યારે સંખ્યાઓ કાયદેસર પસંદગીકાર છે. જ્યારે ટિકિટમાં «બ્રાઉઝર» લખાય અને નિયમસમૂહમાં પોર્ટ-શ્રેણી લાગુ થાય ત્યારે તે કલ્પના બની જાય છે. એ અંતર દસ્તાવેજીકરણની ઝીણવટ નથી. એ નિયમ વચ્ચેનો ફરક છે જેનું તમે સમીક્ષામાં રક્ષણ કરી શકો અને એવા નિયમ વચ્ચેનો જેને કોઈ કસોટી કરી શકતું નથી.
HTTP/3 તમારા TCP નિયમને ચુપચાપ છોડી દે છે
HTTP/3 QUIC પર ચાલે છે, અને QUIC UDP માં વહેવામાં આવે છે. ફક્ત TCP સાથે મેળ ખાતો નિયમ તેને જોઈ શકતો નથી, તેથી જે બ્રાઉઝર તમારા પરીક્ષણ પૃષ્ઠને પસાર કરે છે તે જ પછીની વિનંતી UDP પર મોકલીને ટનલને ટાળી શકે છે, કોઈ પણ સેટિંગ બદલ્યા વિના. RFC 9114 HTTP/3 ને QUIC-આધારિત પ્રોટોકોલ તરીકે વર્ણવે છે, અને સામાન્ય જમાવટમાં QUIC UDP વાપરે છે જેનો મૂળભૂત પોર્ટ 443 છે.
આપેલું બ્રાઉઝર HTTP/3 અજમાવશે કે નહીં તે તેની રૂપરેખા, સાઇટ અને અગાઉનો પ્રયાસ સફળ થયો કે નહીં તેના પર આધાર રાખે છે. એથી યાદશક્તિ પરથી વિચાર કરવો મુશ્કેલ બને છે. તેના બદલે સાધનને પૂછો:
curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'curl લીટી વાટાઘાટ કરેલી આવૃત્તિ છાપે છે, તેથી 3 પુષ્ટિ કરે છે કે UDP માર્ગ વપરાયો. પછી સોકેટ યાદી દર્શાવે છે કે એ જોડાણ ટનલ ઇન્ટરફેસ સાથે બંધાયેલું છે કે ભૌતિક સાથે. જો તમારા curl બિલ્ડમાં HTTP/3 ન હોય, તો ફ્લેગ ચૂપચાપ પાછળ ન હટતાં મોટેથી નિષ્ફળ જાય છે, જે તેની પોતાની નાની દયા છે.
DNS એ અલગ નિર્ણય છે જે તમારે લેવો પડશે
વેબ ટ્રાફિક માટેનો પોર્ટ નિયમ નામ-નિરાકરણ વિશે કંઈ કહેતો નથી. બ્રાઉઝર સિસ્ટમ રિઝોલ્વર, બ્રાઉઝરની અંદર ગોઠવેલું રિઝોલ્વર, અથવા છેલ્લે જોડાયેલા એ પ્રેસ કરેલું રિઝોલ્વર વાપરી શકે છે. તેમાંથી દરેક તમારા નિયમ પસંદ કરે તે માર્ગ કરતાં જુદા માર્ગે પ્રશ્નો મોકલી શકે છે, જેનાથી પરિચિત વિભાજન થાય છે: પૃષ્ઠ લોડ થાય છે, નામ એવી જગ્યાએ ઉકેલાય છે જ્યાં તમે ધાર્યું ન હતું, અને આંતરિક સાઇટ જાહેર સરનામે ઉકેલાય છે અથવા બિલકુલ ઉકેલાતી નથી.
તેને સ્પષ્ટપણે નક્કી કરો. જો આંતરિક નામો ટનલ દ્વારા ઉકેલવાના હોય, તો રિઝોલ્વર તેની અંદર હોવું જોઈએ, અને નિયમસમૂહે તે રિઝોલ્વર તરફ DNS ની પરવાનગી આપવી જોઈએ અને બીજા પ્રશ્નો બહાર રાખવા જોઈએ. જો બ્રાઉઝર જાહેર પ્રદાતા તરફ DNS over HTTPS વાપરે, તો પ્રશ્ન તમારા રિઝોલ્વરને સંપૂર્ણપણે ટાળે છે અને પોર્ટ નિયમ મદદ કરી શકતો નથી. પસંદગીને રૂટિંગ નિયમની સાથે જ એ જ ફેરફાર-નોંધમાં લખો, કારણ કે આગલી નિષ્ફળતા સુધારનાર બંનેને સાથે વાંચે છે.
પછી પૃષ્ઠ સાથે નહીં, રિઝોલ્વર સાથે ચકાસો:
resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'જવાબ ન મળવો એ નિરાકરણની સમસ્યા છે, જ્યારે બ્રાઉઝરનો ભૂલ-સંદેશ નેટવર્કને દોષ આપે ત્યારે પણ. આ બે નિષ્ફળતા વપરાશકર્તાને એકસમાન લાગે છે અને સંપૂર્ણ જુદી ટિકિટ છે.
ત્રણ સીમાઓ, ત્રણ જુદી રીતો
તમે ઈચ્છો છો તે સીમાને નામ આપતાં જ મોટાભાગની ગૂંચવણ અદૃશ્ય થાય છે. એ એકબીજાના બદલે વપરાઈ શકતી નથી, અને ટનલ બંધ પડે ત્યારે દરેકની નિષ્ફળતાની રીત જુદી હોય છે.
| What you actually want | Mechanism that fits | What it does not cover |
|---|---|---|
| These transport ports use this exit | Firewall mark plus policy route | Applications, HTTP/3 over UDP, DNS |
| This browsing session stays separate | Application-aware VPN, or a separate network namespace plus a proxy | Other applications in the same session |
| Only these private sites are reachable | Destination-based routes with private DNS | Public sites on the same address family |
અલગ બ્રાઉઝર પ્રોફાઇલ એ મધ્ય પંક્તિની જાળ છે. તે કૂકીઝ અને ઇતિહાસ અલગ કરે છે, અને યજમાનના રૂટિંગ કોષ્ટકમાં કંઈ બદલતું નથી, તેથી બંને પ્રોફાઇલ એક જ માર્ગે જાય છે. અલગીકરણ માટે કર્નલ જે લાગુ કરે તેવું કંઈક જોઈએ, એટલે કે નામ-અવકાશ, કન્ટેનર અથવા પોતાનું ટનલ ઇન્ટરફેસ ધરાવતી એપ્લિકેશન.
કોઈ પણ પંક્તિ લાગુ પડે, ટનલ પડે ત્યારે શું થવું જોઈએ તે લખો. ઇન્ટરફેસ સાથે અદૃશ્ય થતો ચિહ્ન-આધારિત માર્ગ સામાન્ય રીતે ભૌતિક મૂળભૂત માર્ગ પર પાછો જાય છે, જે fail-open વર્તન છે. તે બ્રાઉઝિંગ માટે સ્વીકાર્ય અને બીજા કોઈ પણ વસ્તુ માટે અસ્વીકાર્ય હોઈ શકે, અને તે નિર્ણય છે, અમલની વિગત નહીં.
તમે આવરી લો છો તેમ કહો છો તે પ્રવાહોની કસોટી કરો
સ્વીકૃતિ કસોટીએ તમે લખેલી સીમાને અનુસરવી જોઈએ, અનુકૂળ હતા તે પોર્ટ નંબરોને નહીં. ટનલ દ્વારા જવું જ પડે તેવો એક પ્રવાહ, ન જવો જોઈએ તેવો એક, અને તમે વિચાર્યું ન હતું તેવું પરિવહન વાપરતો એક પસંદ કરો:
ip route get 203.0.113.40
curl -sS -o /dev/null -w 'v4 %{http_version} %{remote_ip}\n' https://example.com
nft list ruleset | grep -A2 'dport'માર્ગ-શોધ કહે છે કે ગંતવ્ય ખરેખર કયું ઇન્ટરફેસ વાપરે છે, અને એ જ હકીકત છે જે મોટાભાગના અહેવાલો ખોટી કહે છે. curl લીટી વાટાઘાટ કરેલી આવૃત્તિ અને સરનામા-કુટુંબની પુષ્ટિ કરે છે. નિયમસમૂહનું ડમ્પ કસોટી દરમિયાન ઉમેરેલો અને મર્યાદિત કરવાનું ભૂલી ગયેલો નિયમ પકડે છે, અને એમ જ કામચલાઉ ચિહ્ન કાયમી fail-open રૂટિંગ બને છે.
ત્રણેય આઉટપુટ સમય-છાપ સાથે નોંધો અને ફેરફાર સાથે રાખો. પછી કોઈ જાહેર કરે કે «VPN એ ઇન્ટ્રાનેટ તોડી નાખ્યું», ત્યારે ઇચ્છિત સીમા અને અમલમાં મૂકેલી સીમા વચ્ચેનો ફરક એ નોંધમાં દેખાશે, અને સુધારો નિયમ બદલવો હશે, દલીલ નહીં.