పోర్ట్ 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 డిఫాల్ట్ పోర్ట్ 443 ఉన్న UDP ను వాడుతుంది.
ఇచ్చిన బ్రౌజర్ 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 ఇంట్రానెట్ను పాడు చేసింది» అని నివేదిస్తే, ఉద్దేశించిన మరియు అమలు చేసిన హద్దుల మధ్య భేదం ఆ రికార్డులో కనిపిస్తుంది, మరియు సవరణ వాదన కాదు, నియమ మార్పు అవుతుంది.