Reguloj por pordoj 80 kaj 443 ne sendas la retumilon tra VPN

Iu petas, ke la retumilo uzu la tunelon, kaj la peto revenas kiel fajroŝirma regulo kongruanta kun celpordoj 80 kaj 443. Ĝi aspektas preciza kaj ne estas. Porda kongruo elektas pakojn laŭ ilia transporta kaplinio, ne laŭ tio, kiun programon malfermis la ingon, kaj moderna retumado ne limigas sin al tiuj du pordoj sur TCP. La regulo maltrafos iom da trafiko, kiun vi volis inkluzivi, kaj kaptos trafikon, kiun vi neniam intencis tuŝi. Antaŭ ol skribi ĝin, decidu, kiun el tri malsamaj limoj vi efektive volas.

La regulo priskribas transportan klason, ne aplikaĵon

En Linux, celporda kongruo ekzamenas la TCP-kaplinian kaj nenion super ĝi. Marki tiujn pakojn kaj gvidi ilin per politika vojo funkcias ĝuste kiel dokumentite, kaj neniu el tiuj mekanismoj scias, kion signifas la utila ŝarĝo aŭ kiu procezo sendis ĝin. La marko estas numero alkroĉita al pako, ne identeco alkroĉita al aplikaĵo.

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

Du sekvoj tuj sekvas. Programara ĝisdatigilo, kiu kontaktas TCP 443, ricevas la saman traktadon kiel la retumilo, kio povas esti en ordo aŭ povas esti paneo atendanta la sekvan ĝisdatigan ciklon. Kaj reta servo intence publikigita sur alia pordo, diru 8443, falas tute ekster la regulon, kvankam ĝi ankoraŭ estas la reta trafiko, pri kiu zorgis la uzanto.

La nombroj estas legitimaj selektiloj, kiam la postulo vere temas pri tiuj pordoj. Ili fariĝas fikcio, kiam «retumilo» estas skribita en la bileto kaj porda gamo estas efektivigita en la regulnombro. Tiu breĉo ne estas dokumentada subtilaĵo. Ĝi estas la diferenco inter regulo, kiun vi povas defendi en revizio, kaj unu, kiun neniu povas testi.

HTTP/3 kviete forlasas vian TCP-regulon

HTTP/3 funkcias sur QUIC, kaj QUIC estas portata en UDP. Regulo, kiu kongruas nur kun TCP, ne povas vidi ĝin, do la sama retumilo, kiu kontentigas vian testan paĝon, povas sendi postan peton sur UDP kaj preterpasi la tunelon, sen ke iu ajn ŝanĝu agordon. RFC 9114 priskribas HTTP/3 kiel protokolon bazitan sur QUIC, kaj QUIC uzas UDP kun defaŭlta pordo 443 en la ordinara deplojo.

Ĉu donita retumilo provos HTTP/3 dependas de ĝia agordo, de la retejo kaj de tio, ĉu antaŭa provo sukcesis. Tio igas ĝin malbona afero por rezonado el memoro. Demandu la ilon anstataŭe:

curl --http3 -sS -o /dev/null -w '%{http_version} %{time_total}\n' https://example.com
ss -tunp | grep -E ':443\b'

La curl-linio presas la intertraktitan version, do 3 konfirmas, ke la UDP-vojo estis uzata. La ingolisto poste montras, ĉu tiu konekto estas ligita al la tunela interfaco aŭ al la fizika. Se HTTP/3 ne disponeblas en via curl-konstruo, la flago malsukcesas laŭte anstataŭ silente retroiri, kio estas ĝia propra malgranda kompato.

DNS estas aparta decido, kiun vi devas fari

Porda regulo por reta trafiko diras nenion pri nomrezolucio. La retumilo povas uzi la sistemrezolvilon, rezolvilon agorditan ene de la retumilo, aŭ unu puŝitan de tio, kio konektiĝis laste. Ĉiu el ili povas sendi demandojn laŭ alia vojo ol tiu, kiun elektas via regulo, kio produktas la klasikan disigon: la paĝo ŝarĝiĝas, la nomo rezolviĝas ie, kie vi ne atendis, kaj la interna retejo rezolviĝas al publika adreso aŭ tute ne.

Decidu ĝin eksplicite. Se internaj nomoj devas rezolviĝi tra la tunelo, la rezolvilo devas esti ene de ĝi, kaj la regula aro devas permesi DNS al tiu rezolvilo dum ĝi tenas aliajn demandojn ekstere. Se la retumilo uzas DNS over HTTPS al publika provizanto, la demando preterpasas vian rezolvilon tute kaj la porda regulo ne povas helpi. Skribu la elekton en la saman ŝanĝprotokolon kiel la enkursiga regulo, ĉar ambaŭ legas kune tiu, kiu sencimigos la sekvan paneon.

Poste kontrolu per la rezolvilo anstataŭ per la paĝo:

resolvectl query intranet.example.internal
resolvectl status | grep -A3 'Current DNS Server'

Mankanta respondo estas rezolva problemo eĉ kiam la erarmesaĝo de la retumilo kulpas la reton. Tiuj du paneoj aspektas identaj al uzanto kaj estas tute malsamaj biletoj.

Tri limoj, tri malsamaj mekanismoj

Plejparto de la konfuzo malaperas, kiam vi nomas la limon, kiun vi volas. Ili ne estas interŝanĝeblaj, kaj ĉiu havas alian panean reĝimon dum tunela paneo.

Aparta retumila profilo estas la kaptilo en la meza vico. Ĝi apartigas kuketojn kaj historion, kaj ĝi ŝanĝas nenion pri la enkursiga tabelo de la gastiganto, do ambaŭ profiloj iras la saman vojon. Izolado postulas ion, kion la kerno devigas, tio estas nomspaco, ujo aŭ aplikaĵo, kiu posedas sian propran tunelan interfacon.

Kiun ajn vicon aplikiĝas, skribu, kio devus okazi, kiam la tunelo falas. Marka enkursigo, kiu malaperas kun la interfaco, kutime falas reen al la fizika defaŭlta vojo, kio estas fail-open-konduto. Tio povas esti akceptebla por retumado kaj neakceptebla por io ajn alia, kaj ĝi estas decido, ne efektiviga detalo.

Testu la fluojn, kiujn vi asertas kovri

La akcepta testo devas sekvi la limon, kiun vi skribis, ne la pordnumerojn, kiuj estis oportunaj. Elektu unu fluon, kiu devas iri tra la tunelo, unu, kiu ne devas, kaj unu, kiu uzas transporton, pri kiu vi ne pensis:

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'

La vojserĉo diras al vi, kiun interfacon celo efektive uzas, kaj tio estas la fakto, kiun plej multaj raportoj erare nomas. La curl-linio konfirmas la intertraktitan version kaj la adresan familion. La eligo de la regula aro kaptas la regulon, kiun vi aldonis dum testado kaj forgesis limigi, kaj tiel provizora marko fariĝas permanenta fail-open-enkursigo.

Registru ĉiujn tri eligojn kun tempindiko kaj konservu ilin kun la ŝanĝo. Kiam iu poste raportos, ke «la VPN rompis la internan reton», la diferenco inter la intencita kaj la efektivigita limo estos videbla en tiu registro, kaj la riparo estos regula ŝanĝo anstataŭ diskuto.