UFW-escepto por VPN kiam la finpunkta adreso ŝanĝiĝas

La kliento provas rekonektiĝi kaj nenio eliras la maŝinon, kvankam la sama profilo funkciis pasintsemajne. La gastnomo de la finpunkto nun solviĝas al alia adreso, kaj la elira escepto ankoraŭ nomas la malnovan. Tiu sola kaduka permeso sufiĉas por transformi funkciantan kill switch en totalan interrompon, kaj ĝi estas nevidebla en ĉiu statindikilo kiun la labortablo montras. La riparo estas malgranda laborfluo, ne unulinia ŝanĝo.

La tunelo rekonektiĝas, poste nenio eliras

Elira regulo kiu nomas celadreson estas momentfoto, kaj DNS-respondoj ne estas. Kiam la provizanto rotacias adreson, la paketo kiun la kliento sendas al la nova peer kongruas kun nenio kaj estas forĵetita de la implicita malpermeso. La kliento tiam raportas tempolimon, kio sonas kiel servila problemo anstataŭ fajroŝirma.

Fiksi la adreson kiun publika serĉo redonas igas hodiaŭon funkcii kaj lasas morgaŭon rompita. Tio estas unufoja ŝanĝo, ne prizorga politiko.

Priskribu la escepton kiun vi efektive celas

Komencu per skribi la kvar valorojn kiujn la regulo bezonas: la aprobita finpunkta nomo aŭ adresaro, la transporto, la cela pordo kaj la interfaco tra kiu la paketo eliras. Ĉiuj kvar estas parto de la permeso, kaj iu ajn el ili povas esti malĝusta dum la regulo ankoraŭ aspektas kredinda. Regulo kiu estas ĝusta en tri el ili malsukcesas same kiel regulo kiu estas malĝusta en ĉiuj kvar. Skribu ilin antaŭ ol tajpi la komandon, ĉar regulo estas nur tiel bona kiel la priskribo malantaŭ ĝi.

La suba komando montras la formon por unu IPv4 UDP-finpunkto sur kabla uplink. Anstataŭigu ambaŭ valorojn per tiuj kiujn vi kontrolis kontraŭ la deplojo.

sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose

Tiu permeso ne rajtigas arbitrajn celojn sur la sama pordo, ne kreas aŭskultanton kaj ne kovras TCP. La manlibra paĝo de UFW priskribas kiel adreso, interfaco kaj protokolo mallarĝigas regulon, kaj ĝuste tiu mallarĝigo estas la tuta afero.

Refreŝigu ĝin kiel unu laborfluon

Traktu la escepton kiel rimedon kun posedanto kaj transiro, ne kiel komandon kiun iu memoras ruli. Unue akiru kandidaton el la propra solvilo kaj finpunkta inventaro de la deplojo, kaj intence difinu kiel tiu nomo solviĝas antaŭ ol la tunelo ekzistas. Poste validigu la kandidaton kontraŭ la celata protokolo, pordo kaj adresfamilio antaŭ ol tuŝi la regulkolekton.

Unue instalu la novan mallarĝan permeson kaj konfirmu ke ĝi ŝargiĝis, ĉar peti la klienton uzi adreson kiun la fajroŝirmilo ankoraŭ blokas produktas fiaskon kiu aspektas kiel servila paneo. Lasu nerilatajn regulojn netuŝitaj dum la ŝanĝo.

Observu la transiron de la kliento tra sia subtenata rekonekta vojo kaj konfirmu kiun malproksiman adreson ĝi elektis. Nur ĝisdatigi DNS ne movas ekzistantan ingon, kaj agordo pri finpunkta persisteco povas teni la klienton ĉe la malnova peer longe post kiam la rikordo ŝanĝiĝis.

Fine malmuntu la kadukan permeson intence, permesante la aprobitan interkovran fenestron dum malnova sesio ankoraŭ aktivas. Forigi la malnovan rikordon tro frue produktas mallongan interrompon; lasi ĝin por ĉiam lasas permeson kiun neniu povas klarigi.

Intence malmuntu la malnovan permeson

Forigo estas kie kuŝas la plej granda parto de la risko, ĉar la malnova regulo estas la sola afero kiu nun funkcias. Se la instalado de la kandidato malsukcesis, ne daŭrigu kaj ne forviŝu la rikordon kiu ankoraŭ portas trafikon. Se la forigo mem malsukcesas, registru la kadukan permeson kiel kaduka anstataŭ deklari la politikon aktuala.

Ripetu la tutan revizion kiam la uplink ŝanĝiĝas de Ethernet al Wi-Fi, kiam la transporto ŝanĝiĝas, aŭ kiam servo rotacias tra pluraj adresoj. Interfacspecifa regulo devus ĉesi kongrui post reta ŝanĝo, kaj tiu konduto estas ĝusta eĉ se ĝi aspektas kiel regreso.

Pruvu la kontrakton poste per sendanĝera trafiko. La aprobita finpunkto devas esti atingebla dum la agordo, la protektita aplikaĵo devas funkcii post konekto, kaj nerilata rekta trafiko devas resti blokita dum interrompo. Inkludu ambaŭ adresfamiliojn kaj unu intence malsukcesan ĝisdatigan provon, ĉar konekto kiu sukcesas post unu sola ŝanĝo de fiksita adreso pruvas neniun el tiuj kazoj.