UFW išimtis VPN, kai pasikeičia galinio taško adresas

Klientas bando vėl prisijungti, ir iš mašinos nieko neišeina, nors tas pats profilis veikė praėjusią savaitę. Galinio taško mazgo vardas dabar sprendžiamas kitu adresu, o išeinanti išimtis vis dar nurodo senąjį. Šio vieno pasenusio leidimo pakanka, kad veikiantis kill switch taptų visiška klaida, ir jis nematomas jokiame darbalaukio rodomame būsenos indikatoriuje. Taisymas yra nedidelė darbo eiga, o ne vienos eilutės pakeitimas.

Tunelis vėl prisijungia, o tada nieko neišeina

Išėjimo taisyklė, kuri nurodo paskirties adresą, yra momentinė nuotrauka, o DNS atsakymai nėra. Kai teikėjas pasuka adresą, kliento siunčiamas paketas naujo peer link nieko neatitinka ir numetamas pagal numatytąjį draudimą. Tada klientas praneša apie laiko limitą, o tai skamba kaip serverio, o ne ugniasienės problema.

Užfiksuoti adresą, kurį grąžina vieša užklausa, leidžia šiandien veikti ir palieka rytojų sugedusį. Tai vienkartinis pakeitimas, o ne priežiūros politika.

Apibūdinkite išimtį, kurios iš tikrųjų norite

Pradėkite nuo keturių reikšmių, kurių reikia taisyklei, užrašymo: patvirtintas galinio taško vardas arba adresų rinkinys, transportas, paskirties prievadas ir sąsaja, per kurią paketas išeina. Visos keturios yra leidimo dalis, ir bet kuri jų gali būti neteisinga, kol taisyklė vis dar atrodo įtikinamai. Taisyklė, kuri teisinga trijose jų, sugenda lygiai taip pat kaip taisyklė, kuri neteisinga visose keturiose. Užrašykite jas prieš įvesdami komandą, nes taisyklė yra tik tokia gera, kokia yra jos aprašymas.

Toliau pateikta komanda rodo formą vienam IPv4 UDP galiniam taškui laidiniame uplinke. Pakeiskite abi reikšmes tomis, kurias patikrinote diegimo atžvilgiu.

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

Šis leidimas neleidžia savavališkų paskirčių tame pačiame prievade, nesukuria klausytojo ir neapima TCP. UFW vadovo puslapis aprašo, kaip adresas, sąsaja ir protokolas susiaurina taisyklę, ir būtent tas susiaurinimas yra esmė.

Atnaujinkite ją kaip vieną darbo eigą

Traktuokite išimtį kaip išteklių, turintį savininką ir perėjimą, o ne kaip komandą, kurią kas nors prisimena paleisti. Pirmiausia gaukite kandidatą iš paties diegimo resolverio ir galinių taškų inventoriaus, ir sąmoningai apibrėžkite, kaip tas vardas sprendžiamas prieš atsirandant tuneliui. Tada patikrinkite kandidatą numatyto protokolo, prievado ir adresų šeimos atžvilgiu, prieš liesdami taisyklių rinkinį.

Pirmiausia įdiekite naują siaurą leidimą ir patvirtinkite, kad jis įkeltas, nes prašymas klientui naudoti adresą, kurį ugniasienė vis dar blokuoja, sukelia klaidą, kuri atrodo kaip serverio sutrikimas. Keitimo metu nepalieskite nesusijusių taisyklių.

Stebėkite kliento perėjimą palaikomu pakartotinio prisijungimo keliu ir patvirtinkite, kurį nuotolinį adresą jis pasirinko. Vien DNS atnaujinimas neperkelia esamo lizdo, o galinio taško išlikimo nustatymas gali išlaikyti klientą prie seno peer dar ilgai po to, kai įrašas pasikeitė.

Galiausiai sąmoningai atšaukite pasenusį leidimą, leisdami patvirtintą persidengimo langą, kol sena sesija dar aktyvi. Per anksti pašalinus seną įrašą įvyksta trumpa klaida; palikus jį amžinai lieka leidimas, kurio niekas negali paaiškinti.

Sąmoningai atšaukite seną leidimą

Šalinimas yra vieta, kur slypi didžioji dalis rizikos, nes sena taisyklė yra vienintelis dalykas, kuris šiuo metu veikia. Jei kandidato diegimas nepavyko, nesitęskite ir netrinkite įrašo, kuris vis dar neša srautą. Jei pats šalinimas nepavyksta, užregistruokite pasenusį leidimą kaip pasenusį, o ne paskelbkite politiką galiojančia.

Pakartokite visą peržiūrą, kai uplinkas pasikeičia iš Ethernet į Wi-Fi, kai pasikeičia transportas arba kai paslauga sukasi per kelis adresus. Sąsajai specifinė taisyklė turėtų nustoti atitikti po tinklo pakeitimo, ir toks elgesys yra teisingas, nors atrodo kaip regresija.

Tada įrodykite sutartį nekenksmingu srautu. Patvirtintas galinis taškas turi būti pasiekiamas sąrankos metu, apsaugota programa turi veikti prisijungus, o nesusijęs tiesioginis srautas turi likti blokuojamas sutrikimo metu. Įtraukite abi adresų šeimas ir vieną sąmoningai nepavykusį atnaujinimo bandymą, nes ryšys, kuris pavyksta po vieno užfiksuoto adreso pakeitimo, neįrodo nė vieno iš tų atvejų.