Statiske tunneladresser i pfSense: præference eller reservation?

To design ser ens ud på papiret og opfører sig meget forskelligt, når en regel afhænger af dem. Det ene skriver en adresse ind i en klienttilsidesættelse og stoler på adressen som identitet. Det andet lukker dynamisk optagelse helt, så et endepunkt enten har en unik tildeling eller ikke opretter forbindelse. Kun det andet gør en adresse til et politikinput, du kan forsvare, og forskellen er værd at forstå, før du skriver en eneste firewallregel.

Hvad en tilsidesættelsesadresse egentlig lover

En klientspecifik tilsidesættelse bærer valgmuligheder per klient, herunder en foretrukken tunneladresse. Netgate beskriver den adresse som en præference og ikke en reservation, hvilket betyder, at den dynamiske pulje ikke giver adressen op for nogen anden.

Det er som regel fint. En kollision er sjælden, og klienten får normalt det, den bad om, hvilket er nok til bekvemmelighed og ikke nok til autorisation. Bekvemmelighed og autorisation er forskellige krav, og kun ét af dem overlever en kollision.

Med subnettopologi tager feltet klientadressen sammen med servernetværkets maske, så en adresse inde i en 10.90.0.0/24-tunnel skrives som 10.90.0.10/24.

Intet af det reserverer nummeret. En klient, hvis tilsidesættelse ikke matcher, eller en dublet session kan ende andre steder i puljen, og en regel, der er bundet til adressen, beskriver så nogen, der ikke er der.

Luk den dynamiske vej med et afgrænset standardvalg

Alternativet er en udelukkende statisk server: hvert optaget endepunkt har sin egen identitet og sin egen unikke adresse, og intet andet slipper ind.

At implementere det betyder en DEFAULT-tilsidesættelse afgrænset til den ene server med blokering af forbindelser aktiveret. En klient uden en matchende tilsidesættelse kan så ikke falde tilbage på almindelig dynamisk optagelse. Den ene linje er det, der gør en præference til et lukket sæt.

Omfang betyder noget. En standardtilsidesættelse anvendt på hver VPN-instans på maskinen vil låse ikke-relaterede tunneler ude, og den fejl ser ud som en brudt tjeneste snarere end en politikbeslutning. Bind den til den ene server, hvis optagelsesmodel du ændrer. Noter derefter omfanget i ændringsloggen, fordi den næste person ikke vil huske, hvilken tunnel den hører til.

Revider hele det tilladte sæt bagefter. Standardblokeringen retter ikke en navngivet tilsidesættelse, der er efterladt uden adresse, og det endepunkt vil ganske enkelt ikke kunne oprette forbindelse uden et tydeligt vink om hvorfor.

Match den identitet, serveren faktisk bruger

En tilsidesættelse matcher noget. På en server, der matcher certifikaters common names, skal tilsidesættelsesnavnet være det common name, ikke personens visningsnavn. Kopier det fra certifikatet i stedet for fra kontolisten.

En server, der er konfigureret til at bruge brugernavnet som common name, matcher på en helt anden nøgle, og en tilsidesættelse opkaldt efter certifikatet vil aldrig udløse. Læs indstillingen i stedet for at udlede den af, hvad kontolisten viser.

Behold de ekstra autentificeringsfaktorer, som udrulningen kræver. En lukket adressemodel ændrer, hvem der må oprette forbindelse, og hvilken adresse de får; den erstatter ikke certifikatkontrollen eller den anden faktor.

Skriv adgangsreglerne, når kortet er solidt

Når kortet fra identitet til adresse er lukket, kan regler henvise til adresser uden at foregive, at de er personer. Et alias, der grupperer én persons endepunkter, kan nå en bestemt tjeneste, mens et andet alias når noget andet. Aliaset bliver det reviderbare objekt, og adressen bliver en implementeringsdetalje indeni.

Hold destinationer og porte eksplicitte. At tillade hele det lokale netværk fra hele tunnelpuljen er netop det design, som denne øvelse skulle erstatte.

Læs floating-, gruppe- og interfaceregler i deres reelle evalueringsrækkefølge, fordi en tidligere bred passage overtrumfer en senere snæver. At slå intern videresendelse fra klient til klient fra holder peer-trafik på den grænse, hvor disse regler revideres. En regel, der kun findes på papiret, er ikke håndhævelse.

Test de negative tilfælde

Afprøv fire friske forbindelser: et navngivet endepunkt, et helt uden tilsidesættelse, en tjeneste, der burde være tilgængelig, og en, der ikke burde. Det uoplistede endepunkt er det vigtige tilfælde, fordi det er det, designet findes for at stoppe. Hvis det opretter forbindelse, gør standardblokeringen ikke sit arbejde.

Kontrollér IPv6 separat, da en IPv4-adressepolitik intet siger om en anden stak. Bekræft derefter, at applikationen stadig autoriserer brugeren, fordi en tunneladresse er et netværksfaktum og ikke bevis på, hvem der sidder ved tastaturet. Begge kontroller hører i acceptnotatet.

Planlæg til sidst migreringen. Nye tilsidesættelser og snævre regler ændrer ikke allerede etablerede sessioner bagudrettet, så eksisterende tilstande skal udløbe eller ryddes bevidst.