Regels foar poarte 80 en 443 stjoere de browser net troch in VPN
In poartematch kiest TCP-streamen, net in browser. HTTP/3 rint oer UDP, DNS kin in oare wei nimme, en in bywurkingsprogramma treft deselde regel dy't jo skreaun hawwe.
Immen freget oft de browser de tunnel brûke kin, en it antwurd komt werom as in firewallregel dy't op de bestimmingspoarten 80 en 443 past. It liket presys en it is net. In poartematch kiest pakketten op harren ferfierkop, net op hokker programma de socket iepene hat, en modern browsen beheint him net ta dy twa poarten op TCP. De regel sil wat ferkear misse dat jo bedoelden, en ferkear fange dat jo nea oanreitsje woe. Beslis foar it skriuwen hokker fan trije ferskillende grinzen jo eins wolle.
De regel beskriuwt in ferfiermiddelklasse, net in applikaasje
Op Linux ûndersiket in bestimmingspoartematch de TCP-kop en neat dêrboppe. It markearjen fan dy pakketten en it stjoeren fan harren mei in beliedsrûte wurket krekt sa't it dokumintearre is, en gjin fan dy masines wit wat de lading betsjut of hokker proses it stjoerde. De marke is in nûmer dat oan in pakket hinget, net in identiteit dy't oan in applikaasje hinget.
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 100Twa gefolgen komme daliks. In software-updater dy't TCP 443 kontaktet, krijt deselde behanneling as de browser, wat goed wêze kin of in steuring dy't op de folgjende bywurkingssyklus wachtet. En in webservice dy't bewust op in oare poarte publisearre is, sizze 8443, falt hielendal bûten de regel, wylst it noch altiten it webferkear is dat de brûker oan gie.
De nûmers binne legitime selektearden as de eask echt oer dy poarten giet. Se wurde fiksje as "browser" yn it ticket skreaun wurdt en in poartebedrach yn 'e regelset ymplemintearre wurdt. Dat gat is gjin dokumintaasjedetail. It is it ferskil tusken in regel dy't jo yn in beoardieling ferdigenje kinne en ien dy't nimmen testen kin.
HTTP/3 ferlit stilwei jo TCP-regel
HTTP/3 rint oer QUIC, en QUIC wurdt yn UDP droegen. In regel dy't allinnich TCP matcht, kin it net sjen, dat deselde browser dy't jo testside hellet, kin in letter fersyk oer UDP stjoere en de tunnel omgean sûnder dat immen in ynstelling feroaret. RFC 9114 beskriuwt HTTP/3 as in QUIC-basearre protokol, en QUIC brûkt UDP mei in standertpoarte fan 443 yn 'e gewoane útrulling.
Oft in bepaalde browser HTTP/3 besiket, hinget ôf fan syn konfiguraasje, fan 'e side en fan oft in eardere poging slagge. Dat makket it in min ding om út 't ûnthâld oer te riddenearjen. Freegje it ark ynstee:
curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'De curl-regel prints de ûnderhannele ferzje, dat in 3 befêstiget dat de UDP-wei brûkt is. De socketlist lit dan sjen oft dy ferbining oan 'e tunnelinterface of oan 'e fysike bûn is. As HTTP/3 net yn jo curl-bou beskikber is, falt de flagge lûd mis ynstee fan stilwei werom te fallen, wat syn eigen lytse genede is.
DNS is in aparte beslissing dy't jo nimme moatte
In poartregel foar webferkear seit neat oer nammebeslissing. De browser kin de systeemoplosser brûke, in oplosser dy't yn de browser konfigurearre is, of ien dy't de lêste ferbining nei foaren skood hat. Elk fan dy kin fragen oer in oare wei stjoere as dejinge dy't jo regel kiest, wat de klassike splitsing jout: de side laden, de namme wurdt earne oplost dêr't jo it net ferwachten, en de ynterne side oplost nei in iepenbier adres of hielendal net.
Beslis dat eksplisyt. As ynterne nammen troch de tunnel oplost wurde moatte, moat de oplosser der yn wêze, en de regelset moat DNS nei dy oplosser tastean en oare fragen bûten hâlde. As de browser DNS over HTTPS nei in iepenbiere oanbieder brûkt, giet de fraach folslein by jo oplosser lâns en kin de poartregel net helpe. Skriuw de kar yn itselde feroaringsrecord as de rûteringsregel, want de twa wurde tegearre lêzen troch wa't de folgjende flater ûntslút.
Ferifiearje it dan mei de oplosser ynstee fan mei de side:
resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'In ûntbrekkend antwurd is in oplossingsprobleem, sels as de flatermelding fan 'e browser it netwurk de skuld jout. Dy twa flaters sjogge der itselde út foar in brûker en binne hielendal ferskillende tickets.
Trije grinzen, trije ferskillende meganismen
It measte fan 'e betizing ferdwynt sadree't jo de grins neame dy't jo wolle. Se binne net útwikselber, en elk hat in oare flatermodus by in tunnelsteuring.
| 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 |
In apart browserprofyl is de fal yn 'e middelste rige. It skiedt cookies en skiednis, en it feroaret neat oan 'e rûteringstabel fan 'e host, dat beide profilen nimme deselde wei. Isolaasje freget eat dat de kearn hanthavent, dat wol sizze in nammeromte, in kontener of in applikaasje dy't syn eigen tunnelinterface hat.
Hokker rige ek jildt, skriuw op wat der barre moat as de tunnel falt. In mark-basearre rûte dy't mei de interface ferdwynt, falt meastentiids werom op 'e fysike standertrûte, wat fail-open-gedrach is. Dat kin akseptabel wêze foar browsen en net foar eat oars, en it is in beslissing, gjin ymplemintaasjedetail.
Test de streamen dy't jo beweare te dekken
De akseptaasjetest moat de grins folgje dy't jo opskreaun hawwe, net de poartenûmers dy't handich wiene. Kies ien stream dy't troch de tunnel moat, ien dy't net moat, en ien dy't in ferfier brûkt dêr't jo net oan tocht hiene:
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'De rûte-opfreage fertelt jo hokker interface in bestimming eins brûkt, en dat is it feit dat de measte rapporten ferkeard hawwe. De curl-regel befêstiget de ûnderhannele ferzje en de adresfamylje. De útdraai fan 'e regelset fangt de regel dy't jo by it testen tafoege hawwe en fergetten hawwe te beheinen, en sa wurdt in tydlike mark permaninte fail-open-rûtering.
Registrearje alle trije útfieringen mei in tiidstimpel en bewarje se by de feroaring. As immen letter rapportearret dat "de VPN it ynterne netwurk stikken makke hat", dan sil it ferskil tusken de bedoelde en de ymplemintearre grins te sjen wêze yn dat record, en de oplossing sil in regelferoaring wêze ynstee fan in diskusje.