VPN-til-VLAN-adgang: byg matricen før reglerne
Roller på den ene side, tjenester på den anden. Fem kontroller gør et vagt VPN-til-VLAN-design til en tabel, som en firewall-ejer kan implementere.
Start med matricen, ikke med firewall-syntaksen. En tabel med roller på den ene side og tjenester på den anden kan gennemgås af en applikationsejer, diskuteres af en sikkerhedsejer og implementeres af den, der har gatewayen. Den gennemgang er billigere end at fejlfinde regler, som ingen har aftalt.
En times skrivning sparer senere en uges regnskabsarkæologi. Designet handler om, hvem der når hvilken tjeneste, og det er den del, der overlever omnummerering.
Trin 1: navngiv rollerne før netværkene
Start med menneskene, ikke med switchen. Skriv hver gruppe ned, der forbinder eksternt, og den ene sætning, der beskriver, hvad gruppen laver, for eksempel lagerpersonale, der læser lagerbeholdninger, eller en entreprenør, der vedligeholder én integration. Hvis to grupper ville få samme adgang, er de én rolle til dette formål.
Stop her, hvis en rolle kun findes på grund af et organisationsdiagram. En rolle uden et særligt tjenestebehov bliver en række identiske celler, og identiske rækker frister nogen til senere at give et helt subnet for nemheds skyld. Del efter, hvad folk laver, ikke efter hvem der underskriver deres udgifter. Seks roller er normalt for mange til et lille kontor, og tre er ofte rigtigt.
Trin 2: gør hver celle til en tjenesteerklæring
En celle, der siger «Applikationer», kan ikke testes. En celle, der siger «HTTPS til ERP-værten på 443, fra personalepuljen», kan. Erstat hvert netværksnavn med en destination, en protokol og en port, og tilføj derefter den afhængighed, som tjenesten ikke kan fungere uden, for eksempel den interne resolver eller identitetsudbyderen.
| 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 |
Retningskolonnen fanger de dyreste fejl. Tilladelse til at personalet åbner en applikation betyder ikke tilladelse til, at applikationsservere åbner forbindelser tilbage til personalets laptops, og en stateful regel, der tillader den første retning, læses ofte som tilladelse til den anden.
Trin 3: beslut, hvor identitet bliver politik
Nogen skal gøre en autentificeret session til en rolle, som gatewayen kan håndhæve. Understøttede muligheder omfatter gruppepolitik leveret af autentificerings-backenden, betroede sessionsattributter eller separate adressepuljer per rolle. Alle tre virker; et mærke, som klienten sender, virker ikke. Vælg den mekanisme, din gateway dokumenterer, ikke den et forumindlæg beskriver.
At tildele en adresse, der bare ser ud, som om den hører til en VLAN, er det samme ikke-svar i en anden dragt. Netgates vejledning til OpenVPN-firewallregler gør adskillelsen tydelig: at tillade, at tunnelen kommer op, er en anden beslutning end at tillade trafik igennem den.
Skriv ned, hvilken mekanisme du valgte, og hvor den er konfigureret. Når en rolle ændres, er den note forskellen mellem én redigering og en jagt gennem tre grænseflader. Den fortæller også en revisor, hvor der skal kigges først.
Trin 4: hold øje med kildeadressen, som destinationen ser
Videresendelsespolitikken skal matche den virkelige kilde ved grænsen. Hvis gatewayen oversætter VPN-klienter til sin egen adresse, ser hver nedstrøms firewall én kilde og mister evnen til at træffe beslutninger per rolle. Hvis den bevarer klientadressen, skal returvejen findes for den pulje.
Test begge retninger, før du skriver de endelige regler, og noter derefter den observerede kilde ved hver celle. Kør samme kontrol fra to forskellige roller, og sammenlign resultatet. Hvis begge viser gatewayens adresse, er rolledelingen allerede tabt. En matrix, der antager bevarede adresser, mens gatewayen oversætter kilden, fejler ved den første nedstrøms ACL.
Trin 5: test hver celle, før du sender den ud
Gør hver tilladt celle til én repræsentativ handling og hver afvist celle til et negativt tilfælde. Kør begge fra en klient i den faktiske rolle, ikke fra gateway-konsollen, fordi konsollen omgår den vej, du tester.
# 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'Et negativt tilfælde, der forbinder, er et fund, ikke et tilfælde, og det hører i matricen som en fejlet celle, indtil reglen er rettet. Hold testkommandoerne ved siden af tabellen, så den næste anmelder kører dem igen i stedet for at genopbygge ræsonnementet.
Den færdige tabel lever længere end den gateway, den blev skrevet til. Regler ændrer sig med firmware og leverandør, mens rækken, der siger, at en entreprenør når én projekttjeneste, forbliver sand, indtil det arbejde ændrer sig.