Miksi OpenVPN-asiakkaan estosääntö ei koskaan osu FORWARD-ketjuun

Kaksi asiakasta samalla OpenVPN-palvelimella voivat tavoittaa toisensa, vaikka lisäsit niiden poolille DROP-säännön. Sääntö on FORWARD-ketjussa, liikenne virtaa selvästi, ja kyseisen säännön laskuri pysyy nollassa. Luonnollinen johtopäätös on, että palomuuri on rikki. Useammin paketti ei ole edes tullut ketjuun.

On kaksi polkua, joita vertaispaketti voi kulkea OpenVPN-palvelimen läpi, ja ne määrää kokoonpano, ei palomuuri. Tieto siitä, kumpi polku on käytössä, kertoo, onko isäntäsääntö edes oikeassa paikassa.

Kaksi polkua, joita vertaispaketti voi kulkea

Kun sisäisen edelleenlähetyksen valinta on pois päältä, asiakkaan A paketti saapuu tunneliliittymälle, ja sen kohde on asiakkaalle B määritetyn osoitteen sisällä. Palvelimen reititystaulu lähettää sen takaisin saman tunneliliittymän kautta, koska palvelin omistaa reitin B:n osoitteeseen. Se on sisään-ulos-virtaus isäntäkoneen läpi, ja IPv4-edelleenlähetyksen polku arvioi sen.

Kun sisäisen edelleenlähetyksen valinta on päällä, palvelinprosessi sovittaa paketin yhdistettyyn asiakkaaseen ja kirjoittaa sen takaisin suoraan sille asiakkaalle. Paketti käsitellään daemonin sisällä eikä palaa koskaan tunnelilaitteeseen, joten isäntäkoneen edelleenlähetyksen polku ohitetaan kokonaan. OpenVPN 2.6 -käsikirja kuvaa tämän valinnan sisäiseksi asiakkaalta asiakkaalle -edelleenlähetykseksi, ja juuri siksi isäntäkoneen palomuurisääntö ei voi nähdä sitä.

Kolmas muunnelma on asennuksissa, jotka siirtävät datakanavan ydinmoduuliin. Edelleenlähetyspäätös ja salaus siirtyvät pois käyttäjäavaruudesta, ja se, näkeekö netfilter virtauksen, riippuu siitä, miten siirtopolku on rakennettu. Älä koskaan oleta, että vanha sääntöjoukko käyttäytyy siirretyllä palvelimella samoin kuin käyttäjäavaruuden palvelimella. Vahvista tila käynnissä olevasta kokoonpanosta, älä paketin versiosta.

Kun laskuri ei koskaan liiku

Nollalaskuri tarkoittaa, että paketti ei vastannut tuota sääntöä siinä kohdassa, ja syitä on useita. Ensimmäinen on yllä kuvattu ohitus: liikenne ei koskaan saavuttanut ketjua. Toinen on ero liittymässä, suunnassa, lähteessä tai kohteessa, mikä on tavallista, kun pooli numeroitiin uudelleen ja sääntö nimeää yhä vanhan etuliitteen.

Kolmas on sijainti. Ketjussa aiempi sääntö voi hyväksyä virtauksen ennen kuin DROP-sääntösi arvioidaan, ja myöhempi sääntö voi olla se, joka todella ratkaisee tuloksen. Lue ketju järjestyksessä laskurit näkyvissä ja tarkista sitten, minkä säännön luku kasvaa, kun toistat testin.

Tee yksi valvottu vaihto kahden asiakkaan välillä, joiden todelliset osoitteet olet vahvistanut palvelimen omasta tilasta, et muistamastasi vuokrauksesta. Jos asianomainen laskuri ei vielä liiku, epäile polkua ennen kuin kirjoitat sovituksen uudelleen. Jos se liikkuu mutta yhteys onnistuu silti, pudotus ohitetaan myöhemmin ja ongelma on järjestyksessä. Tämä vastaus ratkaisee, onko korjaus säännön muutos vai topologian muutos, joten hanki se ennen kuin muokkaat mitään.

Rajapinnan valinta, joka voi suodattaa

Jos käytännön on elettävä isäntäkoneen palomuurissa, laita liikenne sinne, missä palomuuri voi nähdä sen. Sisäisen edelleenlähetyksen poistaminen käytöstä on tuettu tapa saada vertaisliikenne kulkemaan tunneliliittymän ja edelleenlähetyksen polun läpi, sen kustannuksella, että jokainen vertaispaketti kulkee isäntäkoneen pinon läpi.

Sovita sitten virtaus tarkasti. Liikenne saapuu tunneliliittymälle ja lähtee tunneliliittymältä molempiin suuntiin, joten säännöt, jotka huomioivat vain fyysisen liittymän, eivät sovitu. Osoitepohjaiset säännöt tarvitsevat nykyisen poolin, ja niiden on otettava huomioon paluusuunta yhtä lailla kuin menosuunta.

Monet asennukset hyötyvät enemmän suodattamisesta asiakas- tai ryhmätasolla, missä identiteetti tunnetaan ja käytäntö seuraa käyttäjää eikä osoitetta, joka vaihtuu uudelleenyhdistettäessä. Se on eri mekanismi kuin isäntäketju, eikä niitä kahta pitäisi sekoittaa ilman selvää syytä.

Älä siirrä vanhan topologian sääntöjoukkoa muutoksitta migraation läpi. Osoitepoolit, liittymien nimet ja edelleenlähetystilat vaikuttavat kaikki siihen, sopiiko sääntö, ja kopioitu sääntö, joka ennen toimi, on harhaanjohtavin todisteen muoto. Aloita virtauksesta, jonka haluat sallia, ja kirjoita sääntö, joka vastaa sitä.

Eristyksen testaaminen säännön uskomisen sijaan

Testaa kielletty tapaus ja sallittu tapaus samassa ajossa. Aloita uusi yhteys asiakkaasta toiseen ja vahvista, että se epäonnistuu, ja vahvista sitten, että yhteys, joka pitäisi sallia, toimii edelleen. Jos vain ensimmäinen testataan, kaiken estävä palomuuri näyttää onnistumiselta.

Toista palvelimen kokoonpanon uudelleenlatauksen jälkeen ja kun asiakas yhdistää uudelleen, koska sisäinen edelleenlähetys ja poolien määritykset ovat ajonaikaista tilaa. Tarkista laskurit molempiin suuntiin, sillä sääntö, joka osuu toiseen suuntaan mutta ei vastaukseen, tuottaa osittaisen eristyksen, jota on nopeassa testissä vaikea huomata.

Eristys on havaittu tulos rajalla, joka todella kuljettaa virtauksen. DROP-sääntö jossain isäntäkoneessa ei ole todiste; epäonnistunut yhteys ja sen aiheuttaneen säännön liikahtanut laskuri ovat.