80. un 443. porta noteikumi nenosūta pārlūku caur VPN

Kāds lūdz, lai pārlūks izmantotu tuneli, un atbilde nāk atpakaļ kā ugunsmūra noteikums, kas atbilst galamērķa portiem 80 un 443. Tas izskatās precīzi un nav. Porta atbilstība izvēlas paketes pēc to transporta galvenes, nevis pēc tā, kura programma atvēra ligzdu, un mūsdienu pārlūkošana neaprobežojas ar šiem diviem portiem TCP. Noteikums palaidīs garām daļu satiksmes, ko gribējāt iekļaut, un noķers satiksmi, ko nekad neesat domājis aiztikt. Pirms to rakstāt, izlemiet, kuru no trim dažādajām robežām jūs patiešām gribat.

Noteikums apraksta transporta klasi, nevis lietojumprogrammu

Linux sistēmā galamērķa porta atbilstība pārbauda TCP galveni un neko virs tās. Šo pakešu atzīmēšana un virzīšana ar politikas maršrutu darbojas tieši tā, kā dokumentēts, un neviens no šiem mehānismiem nezina, ko nozīmē lietderīgā slodze vai kurš process to nosūtīja. Atzīme ir numurs, kas piestiprināts paketei, nevis identitāte, kas piestiprināta lietojumprogrammai.

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

Tūlīt seko divas sekas. Programmatūras atjauninātājs, kas sazinās ar TCP 443, saņem tādu pašu attieksmi kā pārlūks, un tas var būt labi vai var būt pārtraukums, kas gaida nākamo atjaunināšanas ciklu. Un tīmekļa pakalpojums, kas apzināti publicēts citā portā, teiksim 8443, pilnībā izkrīt ārpus noteikuma, lai gan tas joprojām ir tas tīmekļa trafiks, kas lietotājam rūpēja.

Skaitļi ir likumīgi atlasītāji, kad prasība patiešām ir par šiem portiem. Tie kļūst par izdomājumu, kad biļetē rakstīts «pārlūks» un noteikumu kopā ieviests portu diapazons. Šī plaisa nav dokumentācijas sīkums. Tā ir atšķirība starp noteikumu, ko jūs varat aizstāvēt pārskatā, un tādu, ko neviens nevar pārbaudīt.

HTTP/3 klusi pamet jūsu TCP noteikumu

HTTP/3 darbojas uz QUIC, un QUIC tiek pārnests UDP. Noteikums, kas atbilst tikai TCP, to nevar redzēt, tāpēc tas pats pārlūks, kas iztur jūsu testa lapu, var nosūtīt vēlāku pieprasījumu pa UDP un apiet tuneli, nevienam nemainot iestatījumu. RFC 9114 apraksta HTTP/3 kā uz QUIC balstītu protokolu, un QUIC izmanto UDP ar noklusējuma portu 443 ierastā izvietojumā.

Vai konkrēts pārlūks mēģinās HTTP/3, ir atkarīgs no tā konfigurācijas, vietnes un tā, vai iepriekšējais mēģinājums izdevās. Tāpēc par to ir slikti spriest no atmiņas. Jautājiet rīkam:

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

curl rinda izdrukā saskaņoto versiju, tāpēc 3 apstiprina, ka tika izmantots UDP ceļš. Pēc tam ligzdu saraksts parāda, vai savienojums ir piesaistīts tuneļa saskarnei vai fiziskajai. Ja jūsu curl būvējumā nav HTTP/3, karodziņš neizdodas skaļi, nevis klusi atkāpjas, un tā ir tā paša mazā žēlastība.

DNS ir atsevišķs lēmums, kas jums jāpieņem

Tīmekļa trafika porta noteikums neko nepasaka par nosaukumu atrisināšanu. Pārlūks var izmantot sistēmas atrisinātāju, pārlūka iekšienē konfigurētu atrisinātāju vai to, ko iespieda pēdējais savienojums. Katrs no tiem var sūtīt vaicājumus pa citu ceļu nekā tas, ko izvēlas jūsu noteikums, un tas rada klasisko šķelšanos: lapa ielādējas, nosaukums tiek atrisināts vietā, kur negaidījāt, un iekšējā vietne tiek atrisināta uz publisku adresi vai nemaz.

Izlemiet to skaidri. Ja iekšējie nosaukumi jāatrisina caur tuneli, atrisinātājam jābūt tā iekšienē, un noteikumu kopai jāatļauj DNS uz šo atrisinātāju, turot citus vaicājumus ārpusē. Ja pārlūks izmanto DNS over HTTPS uz publisku pakalpojumu sniedzēju, vaicājums pilnībā apiet jūsu atrisinātāju un porta noteikums nevar palīdzēt. Ierakstiet izvēli tajā pašā izmaiņu ierakstā kā maršrutēšanas noteikumu, jo abus kopā lasa tas, kas atkļūdos nākamo kļūmi.

Pēc tam pārbaudiet ar atrisinātāju, nevis ar lapu:

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

Trūkstoša atbilde ir atrisināšanas problēma arī tad, kad pārlūka kļūdas ziņojums vaino tīklu. Šīs divas kļūmes lietotājam izskatās vienādi un ir pilnīgi dažādas biļetes.

Trīs robežas, trīs dažādi mehānismi

Lielākā daļa apjukuma pazūd, tiklīdz nosaucat vēlamo robežu. Tās nav savstarpēji aizstājamas, un katrai ir cits atteices režīms tuneļa pārtraukuma laikā.

Atsevišķs pārlūka profils ir vidējās rindas slazds. Tas atdala sīkfailus un vēsturi un neko nemaina resursdatora maršrutēšanas tabulā, tāpēc abi profili iet to pašu ceļu. Izolācijai vajag kaut ko, ko uzspiež kodols, proti, nosaukumvietu, konteineru vai lietojumprogrammu, kurai ir sava tuneļa saskarne.

Lai kura rinda būtu spēkā, pierakstiet, kam jānotiek, kad tunelis krīt. Uz atzīmes balstīts maršruts, kas pazūd kopā ar saskarni, parasti atkrīt uz fizisko noklusējuma maršrutu, un tā ir fail-open uzvedība. Tas var būt pieņemami pārlūkošanai un nepieņemami visam citam, un tas ir lēmums, nevis ieviešanas detaļa.

Pārbaudiet plūsmas, kuras jūs apgalvojat, ka aptverat

Pieņemšanas testam jāseko jūsu pierakstītajai robežai, nevis ērtajiem porta numuriem. Izvēlieties vienu plūsmu, kurai jāiet caur tuneli, vienu, kurai nevajag, un vienu, kas izmanto transportu, par ko neiedomājāties:

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'

Maršruta vaicājums pasaka, kuru saskarni galamērķis patiešām izmanto, un tas ir fakts, ko vairums ziņojumu norāda nepareizi. curl rinda apstiprina saskaņoto versiju un adrešu saimi. Noteikumu kopas izdruka noķer noteikumu, ko pievienojāt testēšanas laikā un aizmirsāt ierobežot, un tā pagaidu atzīme kļūst par pastāvīgu fail-open maršrutēšanu.

Reģistrējiet visas trīs izvades ar laika zīmogu un glabājiet tās kopā ar izmaiņām. Kad vēlāk kāds ziņos, ka «VPN salauza iekštīklu», atšķirība starp paredzēto un ieviesto robežu būs redzama šajā ierakstā, un labojums būs noteikuma maiņa, nevis strīds.