Miksi VPN-rajapintasi jättää jatkuvasti firewalld-vyöhykkeensä
Vyöhyke pysyy, kunnes tunneli yhdistää uudelleen, ja sitten se on poissa. Selvitä, omistaako NetworkManager vai firewalld kyseisen rajapinnan ennen kuin liität komennon.
Lisäät tun0:n oikeaan vyöhykkeeseen, sovellus alkaa toimia ja korjaus haihtuu seuraavassa uudelleenyhdistämisessä. Saman komennon suorittaminen uudelleen toimii, mikä saa sen näyttämään siltä, että firewalld unohti. Se ei unohtanut; jokin, jolla on vahvempi vaade kyseiseen rajapintaan, määritti sen uudelleen.
Vyöhyke pysyy, kunnes rajapinta luodaan uudelleen
firewalld-vyöhykkeen määritys rajapinnalle on sidonta, ja sidonnat ovat kytkettyjä rajapintaobjektiin sellaisena kuin se nyt on. VPN-asiakas, joka purkaa laitteen ja luo sen uudelleen, tuottaa uuden objektin, ja uusi alkaa siitä, mitä määrittävä komponentti sanoo. Siksi oire toistuu jokaisessa uudelleenyhdistämisessä eikä jokaisessa paketissa.
Sama logiikka selittää uudelleenkäynnistyksen käyttäytymisen: ajonaikaiset sidonnat eivät selviä uudelleenkäynnistyksestä, ja pysyvät sidonnat koskevat vain laitteita, jotka firewalld uskoo omistavansa.
Ennen kuin muutat mitään, selvitä, mikä komponentti määrittää vyöhykkeen.
Lue kolme asiaa ennen kuin muutat mitään
Kirjaa vyöhyke, joka rajapinnalla on nyt, aktiiviset vyöhykkeet rajapintoineen ja pysyvä rajapintaluettelo vyöhykkeelle, jota aiot. Suorita nuo kyselyt ennen muutosta, uudelleenyhdistämisen jälkeen ja uudelleenkäynnistyksen jälkeen. Kolmen tuloksen vertaaminen kertoo, korvataanko sidonta, jätetäänkö se huomiotta vai sovelletaanko sitä vain myöhässä. Jos pysyvä luettelo jo nimeää laitteen, kun taas ajonaikainen vyöhyke on eri mieltä, jokin ohittaa muutoksesi.
Kirjaa myös laitteen todellinen nimi joka vaiheessa, koska tunneli, joka laskeutuu tänään tun0:lle, voi laskeutua huomenna tun1:lle.
Yleisnimeen tallennettu sidonta ei ole henkilöllisyyden tarkistus, ja kaksi minuuttia kirjaamista säästää tunnin arvailua.
Kun NetworkManager omistaa yhteyden
Jos NetworkManager hallitsee VPN-yhteyttä, sen profiili kantaa vyöhykkeen ja välittää sen firewalldille, kun yhteys aktivoituu. Pysyvä firewalld-rajapintasidonta samalle laitteelle voidaan silloin jättää huomiotta, koska omistaja on NetworkManager. Aseta vyöhyke yhteydelle ja varmista, että muokkaat VPN-profiilia etkä erillistä fyysistä yhteyttä tai väliaikaista tietuetta.
Kyseisen ominaisuuden muuttaminen voi vaikuttaa aktiiviseen yhteyteen välittömästi.
Pidä hallintapolku saatavilla ja lue kohdevyöhykkeen käytäntö ennen sen soveltamista. ifcfg-tiedoston ZONE-kentän muokkaaminen on oikein vain siellä, missä kyseinen tiedosto on edelleen kokoonpanon lähde.
Kun firewalld omistaa sidonnan
Itsenäiselle tunnelille, jonka rajapintanimi on tarkoituksella vakaa, pysyvä rajapintamuutos on oikea työkalu. Käytä sitä sen uudelleenlatauksen tai elinkaaren kautta, jota käyttöönotto käyttää, ja tarkista sitten ajonaikainen tila, koska vain pysyvä muutos kuvaa aikomusta eikä sitä, mikä on aktiivista. Ne kaksi voivat olla eri mieltä niin kauan kuin uudelleenlataus kestää.
Jos rajapintanimi on dynaaminen, ylläpidä määritystä yhteyden elinkaaren ajan sen sijaan, että kilpailisit sen tunnelin kanssa, joka vaatii nimen ensimmäisenä.
Älä heitä rajapintaa trusted-vyöhykkeelle vain saadaksesi sovelluksen toimimaan.
Testaa uudelleenlataus, uudelleenyhdistäminen ja uudelleenkäynnistys
Muutos on valmis vasta, kun se selviää kaikista kolmesta.
Lataa ensin uudelleen, koska siellä vain ajonaikaiset muutokset katoavat. Yhdistä sitten tunneli uudelleen, koska siellä korvattu rajapinta menettää sidontansa. Käynnistä sitten uudelleen, koska siellä omistajan epäsuhta lopulta paljastuu. Kirjaa vyöhyke jokaisessa vaiheessa ja vertaa sitä kirjaamaasi aikomukseen, ja merkitse, mikä vaihe tuotti eron.
Jos vyöhyke on oikein ja sovellus silti epäonnistuu, ongelma on vyöhykkeen säännöissä tai lähteeseen perustuvassa luokittelussa, ei jäsenyydessä. firewalldin dokumentaatio yhteyksistä ja rajapinnoista on viite siihen, miten omistajuuden pitäisi toimia.
Kirjoita omistaja, arvo ja odotettu tulos runbookiin, ja seuraava uudelleenmääritys on selitettävissä.