UFW erand VPN-ile, kui lõpp-punkti aadress muutub
Kill switch lubab endiselt eilset peeri, samal ajal kui VPN-i hostinimi laheneb mujale. Värskenda UFW erandit ühe hooldatava töövooguna.
Klient proovib uuesti ühendust luua ja masinast ei välju midagi, kuigi sama profiil töötas eelmisel nädalal. Lõpp-punkti hostinimi laheneb nüüd teisele aadressile ja väljuv erand nimetab endiselt vana. Sellest ühest aegunud loast piisab, et muuta töötav kill switch täielikuks katkestuseks, ja see on nähtamatu igas töölaua olekunäidikus. Parandus on väike töövoog, mitte üherealine muudatus.
Tunnel ühendub uuesti ja siis ei välju midagi
Väljuv reegel, mis nimetab sihtaadressi, on hetktõmmis, ja DNS-vastused ei ole. Kui teenusepakkuja aadressi roteerib, ei vasta pakett, mille klient uue peeri poole saadab, millelegi ja vaikekeeld viskab selle kõrvale. Seejärel teatab klient ajastuse ületamisest, mis kõlab pigem serveri kui tulemüüri probleemina.
Avaliku päringu tagastatava aadressi kinnitamine paneb täna töötama ja jätab homse katki. See on ühekordne muudatus, mitte hoolduspoliitika.
Kirjelda erandit, mida sa tegelikult mõtled
Alusta nelja väärtuse üleskirjutamisest, mida reegel vajab: kinnitatud lõpp-punkti nimi või aadressikogum, transport, sihtport ja liides, mille kaudu pakett väljub. Kõik neli on loa osa ja ükskõik milline neist võib olla vale, samal ajal kui reegel näib endiselt usutav. Reegel, mis on õige kolmes neist, ebaõnnestub täpselt samamoodi nagu reegel, mis on vale kõigis neljas. Kirjuta need üles enne käsu tippimist, sest reegel on ainult nii hea kui selle taga olev kirjeldus.
Allolev käsk näitab kuju ühe IPv4 UDP lõpp-punkti jaoks juhtmega ühendusel. Asenda mõlemad väärtused nendega, mille sa juurutuse vastu kontrollisid.
sudo ufw allow out on enp3s0 proto udp to 192.0.2.44 port 1194
sudo ufw status verbose
See luba ei volita samal pordil suvalisi sihtkohti, ei loo kuulajat ega kata TCP-d. UFW käsiraamatu leht kirjeldab, kuidas aadress, liides ja protokoll reeglit kitsendavad, ja just see kitsendamine ongi mõte.
Värskenda seda ühe töövooguna
Käsitle erandit ressursina, millel on omanik ja üleminek, mitte käsuna, mille käivitamist keegi mäletab. Kõigepealt hangi kandidaat juurutuse enda resolverist ja lõpp-punktide loendist ning määra teadlikult, kuidas see nimi enne tunneli olemasolu lahendatakse. Seejärel valideeri kandidaat kavandatud protokolli, pordi ja aadressiperekonna vastu enne reeglistiku puutumist.
Paigalda esmalt uus kitsas luba ja kinnita, et see laaditi, sest kliendi saatmine aadressile, mille tulemüür endiselt blokeerib, tekitab tõrke, mis näeb välja nagu serveri rike. Muudatuse ajal jäta mitteseotud reeglid puutumata.
Jälgi kliendi üleminekut selle toetatud taasthenduse teel ja kinnita, millise kaugema aadressi see valis. Ainult DNS-i uuendamine ei liiguta olemasolevat socketit ja lõpp-punkti püsivuse seade võib hoida klienti vana peeri juures kaua pärast kirje muutumist.
Lõpuks eemalda aegunud luba teadlikult, lubades kinnitatud kattuvusakent, kuni vana sessioon on endiselt aktiivne. Vana kirje liiga varajane eemaldamine tekitab lühikese katkestuse; selle igavesti jätmine jätab loa, mida keegi ei oska seletada.
Eemalda vana luba teadlikult
Eemaldamine on koht, kus istub suurem osa riskist, sest vana reegel on praegu ainus, mis töötab. Kui kandidaadi paigaldamine ebaõnnestus, ära jätka ja kustuta kirjet, mis ikka veel liiklust kannab. Kui eemaldamine ise ebaõnnestub, märgi aegunud luba aegunuks, selle asemel et kuulutada poliitika kehtivaks.
Korda kogu ülevaatust, kui ühendus muutub Ethernetilt Wi-Fi-le, kui transport muutub või kui teenus roteerub mitme aadressi vahel. Liidesespetsiifiline reegel peaks pärast võrgu muutust lakkama sobimast, ja see käitumine on õige, kuigi see näeb välja nagu regressioon.
Tõesta leping pärast seda kahjutu liiklusega. Kinnitatud lõpp-punkt peab seadistamise ajal olema kättesaadav, kaitstud rakendus peab pärast ühendamist töötama ja mitteseotud otsene liiklus peab katkestuse ajal blokeerituks jääma. Hõlma mõlemad aadressiperekonnad ja üks teadlikult ebaõnnestunud uuenduskatse, sest ühendus, mis õnnestub pärast üht kinnitatud aadressi muudatust, ei tõesta ühtki neist juhtudest.