VPN-tot-VLAN-toegang: bou eers die matriks, dan die reëls
Rolle aan die een kant, dienste aan die ander kant. Vyf kontroles verander ’n vae VPN-tot-VLAN-ontwerp in ’n tabel wat ’n firewall-eienaar kan implementeer.
Begin met die matriks, nie met die firewall-sintaks nie. ’n Tabel met rolle aan die een kant en dienste aan die ander kant kan deur ’n toepassingseienaar nagegaan word, deur ’n sekuriteitseienaar betwis word en geïmplementeer word deur wie ook al die gateway hou. Daardie hersiening is goedkoper as om reëls te ontfout waaroor niemand ooit saamgestem het nie.
’n Uur se skryfwerk spaar later ’n week se reëls-argeologie. Die ontwerp praat oor wie watter diens bereik, en dit is die deel wat hernommering oorleef.
Stap 1: noem die rolle voordat jy die netwerke noem
Begin by die mense, nie by die switch nie. Skryf elke groep neer wat op afstand koppel, plus die enkele sin wat beskryf wat daardie groep doen, soos pakhuiswerkers wat voorraadvlakke lees of ’n kontrakteur wat een integrasie onderhou. As twee groepe dieselfde toegang sou kry, is hulle vir hierdie doel een rol.
Stop hier as ’n rol net bestaan weens ’n organogram. ’n Rol sonder ’n eiesoortige diensbehoefte word ’n ry identiese selle, en identiese rye nooi iemand uit om later geriefshalwe ’n hele subnet toe te ken. Verdeel volgens wat mense doen, nie volgens wie hul uitgawes onderteken nie. Ses rolle is gewoonlik te veel vir ’n klein kantoor en drie is dikwels reg.
Stap 2: maak van elke sel ’n diensverklaring
’n Sel wat “Toepassings” sê, is nie toetsbaar nie. ’n Sel wat “HTTPS na die ERP-gasheer op 443, uit die personeelpoel” sê, is. Vervang elke netwerknaam met ’n bestemming, ’n protokol en ’n poort, en voeg dan die afhanklikheid by waarsonder die diens nie kan werk nie, soos die interne oplosser of die identiteitsverskaffer.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
Die rigtingkolom vang die duurste foute. Toestemming vir personeel om ’n toepassing oop te maak, impliseer nie toestemming vir toepassingbedieners om verbindings terug na personeelskootrekenaars oop te maak nie, en ’n toestandvaste reël wat die eerste rigting toelaat, word dikwels gelees asof dit die tweede toelaat.
Stap 3: besluit waar identiteit beleid word
Iemand moet ’n geauthentiseerde sessie omskakel in ’n rol wat die gateway kan afdwing. Ondersteunde opsies sluit in groepsbeleid wat deur die verifikasie-agterkant gelewer word, vertroude sessie-eienskappe, of aparte adrespoele per rol. Al drie werk; ’n etiket wat die kliënt stuur, werk nie. Kies die meganisme wat jou gateway dokumenteer, nie dié wat ’n forumplasing beskryf nie.
Om ’n adres toe te ken wat bloot lyk asof dit aan ’n VLAN behoort, is dieselfde nie-antwoord in ’n ander kostuum. Die Netgate-gids oor OpenVPN-firewallreëls maak die skeiding duidelik: om die tonnel te laat opkom is ’n ander besluit as om verkeer daardeur te laat.
Skryf neer watter meganisme jy gekies het en waar dit gekonfigureer is. Wanneer ’n rol verander, is daardie nota die verskil tussen een wysiging en ’n jag deur drie koppelvlakke. Dit wys ook vir ’n ouditeur waar om eerste te kyk.
Stap 4: let op die bronadres wat die bestemming sien
Stuurbeleid moet by die grens by die werklike bron pas. As die gateway VPN-kliënte na sy eie adres vertaal, sien elke stroomaf-firewall een bron en verloor die vermoë om per rol besluite te neem. As dit die kliëntadres bewaar, moet die terugroete vir daardie poel bestaan.
Toets beide rigtings voordat jy die finale reëls skryf, en teken dan die waargenome bron langs elke sel aan. Hardloop dieselfde kontrole uit twee verskillende rolle en vergelyk die resultaat. As albei die gateway-adres wys, is die rolonderskeid reeds verlore. ’n Matriks wat bewaarde adresse veronderstel terwyl die gateway bronvertaling doen, faal by die eerste stroomaf-ACL.
Stap 5: toets elke sel voordat jy dit uitrol
Skakel elke toegelate sel om in een verteenwoordigende bewerking en elke geweierde sel in ’n negatiewe geval. Hardloop albei van ’n kliënt in die werklike rol, nie van die gateway-konsole nie, want die konsole omseil die pad wat jy toets.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'
’n Negatiewe geval wat konnekteer, is ’n bevinding, nie ’n toeval nie, en dit hoort in die matriks as ’n mislukte sel totdat die reël reggemaak is. Hou die toetsopdragte langs die tabel sodat die volgende keurder hulle herhardloop eerder as om die redenasie te herbou.
Die voltooide tabel oorleef die gateway waarvoor dit geskryf is. Reëls verander saam met firmware en verskaffer, terwyl die ry wat sê dat ’n kontrakteur een projekdiens bereik, waar bly totdat daardie werk verander.