Staattiset tunneliosoitteet pfSensessä: mieltymys vai varaus?

Kaksi ratkaisua näyttävät paperilla samanlaisilta ja käyttäytyvät hyvin eri tavoin, kun sääntö riippuu niistä. Toinen kirjoittaa osoitteen asiakaskohtaiseen ohitukseen ja luottaa osoitteeseen identiteettinä. Toinen sulkee dynaamisen hyväksynnän kokonaan, joten päätelaite joko saa yksilöllisen osoituksen tai ei yhdistä lainkaan. Vain jälkimmäinen tekee osoitteesta käytännön, jota voit puolustaa, ja ero kannattaa ymmärtää ennen kuin kirjoitat yhtäkään palomuurisääntöä.

Mitä ohitusosoite todella lupaa

Asiakaskohtainen ohitus sisältää asiakaskohtaisia asetuksia, muun muassa toivotun tunneliosoitteen. Netgate kuvaa osoitetta mieltymykseksi eikä varaukseksi, mikä tarkoittaa, että dynaaminen pooli ei luovu osoitteesta kenenkään muun hyväksi.

Se on yleensä kunnossa. Törmäys on harvinainen, ja asiakas saa yleensä pyytämänsä, mikä riittää mukavuuteen mutta ei valtuutukseen. Mukavuus ja valtuutus ovat eri vaatimuksia, ja vain toinen niistä kestää törmäyksen.

Aliverkkotopologiassa kenttä ottaa asiakkaan osoitteen yhdessä palvelimen verkon peitteen kanssa, joten osoite 10.90.0.0/24-tunnelin sisällä kirjoitetaan muotoon 10.90.0.10/24.

Mikään tästä ei varaa numeroa. Asiakas, jonka ohitus ei vastaa, tai kaksoisistunto voi päätyä muualle pooliin, ja osoitteeseen sidottu sääntö kuvaa silloin jotakuta, joka ei ole siellä.

Sulje dynaaminen polku rajallisella oletusarvolla

Vaihtoehto on vain staattinen palvelin: jokaisella hyväksytyllä päätelaitteella on oma identiteettinsä ja oma yksilöllinen osoitteensa, eikä mitään muuta pääse sisään.

Sen toteuttaminen tarkoittaa DEFAULT-ohitusta, joka on rajattu tuohon yhteen palvelimeen ja jossa yhteyksien estäminen on käytössä. Asiakas, jolla ei ole vastaavaa ohitusta, ei silloin voi pudota tavalliseen dynaamiseen hyväksyntään. Juuri tuo yksi rivi muuttaa mieltymyksen suljetuksi joukoksi.

Laajuudella on väliä. Oletusohitus, joka kohdistetaan jokaiseen laitteen VPN-instanssiin, sulkee pois asiaankuulumattomia tunneleita, ja tuo vika näyttää rikkoutuneelta palvelulta eikä käytäntöpäätökseltä. Sido se yhteen palvelimeen, jonka hyväksyntämallia olet muuttamassa. Merkitse laajuus sitten muutoslokiin, koska seuraava henkilö ei muista, mihin tunneliin se kuuluu.

Tarkasta koko sallittu joukko jälkeenpäin. Oletusesto ei korjaa nimettyä ohitusta, joka jäi ilman osoitetta, ja tuo päätelaite yksinkertaisesti epäonnistuu yhdistämisessä ilman selvää vihjettä syystä.

Täsmää identiteettiin, jota palvelin todella käyttää

Ohitus täsmää johonkin. Palvelimella, joka täsmää varmenteiden common name -nimiin, ohituksen nimen on oltava tuo common name, ei henkilön näyttönimi. Kopioi se varmenteesta äläkä tililuettelosta.

Palvelin, joka on määritetty käyttämään käyttäjänimeä common namena, täsmää täysin eri avaimeen, eikä varmenteen mukaan nimetty ohitus koskaan laukea. Lue asetus sen sijaan, että päättelet sen siitä, mitä tililuettelo näyttää.

Säilytä käyttöönoton vaatimat lisätodennuskeinot. Suljettu osoitemalli muuttaa sitä, kuka saa yhdistää ja minkä osoitteen hän saa; se ei korvaa varmenteen tarkistusta tai toista tekijää.

Kirjoita käyttösäännöt, kun kartta on kunnossa

Kun identiteetin ja osoitteen kartta on suljettu, säännöt voivat viitata osoitteisiin teeskentelemättä, että ne ovat ihmisiä. Alias, joka ryhmittelee yhden henkilön päätelaitteet, voi tavoittaa tietyn palvelun, kun taas toinen alias tavoittaa jotain muuta. Aliasesta tulee tarkasteltava objekti, ja osoitteesta tulee sen sisäinen toteutusyksityiskohta.

Pidä kohteet ja portit eksplisiittisinä. Koko paikallisen verkon salliminen koko tunnelipoolista on juuri se ratkaisu, joka tämän harjoituksen oli tarkoitus korvata.

Lue floating-, ryhmä- ja käyttöliittymäsäännöt niiden todellisessa arviointijärjestyksessä, koska aikaisempi laaja läpäisy kumoaa myöhemmän kapean. Asiakkaiden välisen sisäisen edelleenlähetyksen poistaminen pitää vertaisliikenteen sillä rajalla, jossa nämä säännöt tarkastetaan. Sääntö, joka on olemassa vain paperilla, ei ole valvontaa.

Testaa kielteiset tapaukset

Kokeile neljää tuoretta yhteyttä: nimetty päätelaite, sellainen jolla ei ole lainkaan ohitusta, palvelu jonka pitäisi olla tavoitettavissa ja sellainen jonka ei pitäisi. Listaamaton päätelaite on tärkeä tapaus, koska juuri sen estämiseksi ratkaisu on olemassa. Jos se yhdistää, oletusesto ei tee tehtäväänsä.

Tarkista IPv6 erikseen, koska IPv4-osoite käytäntö ei kerro mitään toisesta pinosta. Vahvista sitten, että sovellus edelleen valtuuttaa käyttäjän, koska tunneliosoite on verkostototuus eikä todiste siitä, kuka on näppäimistöllä. Molemmat tarkistukset kuuluvat hyväksyntämuistioon.

Suunnittele lopuksi siirtymä. Uudet ohitukset ja kapeat säännöt eivät muuta jo muodostettuja istuntoja taannehtivasti, joten olemassa olevien tilojen on vanhennuttava tai ne on tyhjennettävä tarkoituksella.