Toegang tussen twee met VPN verbonden kantoren beperken

Een site-naar-site-tunnel beantwoordt één vraag, of de twee kantoren pakketten kunnen uitwisselen, en laat de belangrijke open: welk filiaalapparaat welk centrale dienst mag bereiken. De tunnel als wederzijds vertrouwen behandelen is hoe een gastlaptop op hetzelfde pad als de financiële server belandt. De oplossing is geen betere tunnel, maar een uitdrukkelijke toestemmingslijst die na de ontsleuteling wordt gehandhaafd. Deze handleiding brengt die lijst van definitie naar een bewezen weigering.

Werk in deze volgorde en verbreed de tunnelroute niet voordat de beleidsstappen hieronder slagen.

Schrijf de matrix voordat je de gateway aanraakt

Een bruikbare rij noemt drie dingen: een bromgroep, een doelhost of dienstnetwerk, en het protocol en de poort die de toepassing werkelijk gebruikt. Het filiaal en het datacenter zijn geen vermeldingen. Privé-DNS en authenticatiediensten verdienen eigen rijen alleen wanneer de toepassing zonder hen niet kan werken.

Groepeer bronnen op rol en niet op subnetgemak: personeel, gasten, beheer. Wanneer alle drie één plat LAN delen, kan de gateway ze op de netwerklaag niet onderscheiden, dus identiteitscontroles of segmentering moeten eerst komen. Zet de matrix daarna op schrift, met een eigenaar en een herzieningsdatum op elke rij.

Handhaaf waar de pakketten worden ontsleuteld

De regels die IKE en ESP toestaan, bouwen alleen de buitenste tunnel. Binnenverkeer komt onversleuteld aan op de tunnelinterface, en daar hoort de toestemmingslijst: een doorstuurketen op het ontsleutelende apparaat, standaard drop, één regel per matrixrij. Op Linux-gateways betekent dat doorsturen ingeschakeld en filterregels op het tunnelapparaat, niet op de fysieke uplink, zoals de doorstuurhandleiding van strongSwan uitlegt.

Verkeersselectoren zijn een routeringsbeslissing, geen autorisatiebeslissing. Een brede selector die beide subnetten dekt, kan voor routing juist zijn terwijl de firewall nog steeds alleen TCP 443 naar één host toestaat. De selector wordt voor de tunnel onderhandeld en beschrijft wat erin mag binnenkomen, niet wat een bepaald apparaat mag gebruiken. Verbreed nooit een firewallregel omdat de selector breed is.

iptables -A FORWARD -i tun0 -s 10.20.0.0/24 -d 10.10.5.10 -p tcp --dport 443 -j ACCEPT
iptables -A FORWARD -i tun0 -j DROP

NAT en overlappende subnetten veranderen de regels

Wanneer de filiaal-gateway elke host vóór de tunnel naar één adres vertaalt, valt elke brongebaseerde rij in dat ene adres samen. Stop dan met het vertalen van tunnelverkeer, of accepteer dat regels op iets anders moeten steunen, zoals het oorspronkelijke bronadres dat vóór de vertaling is vastgelegd. De verre kant heeft hetzelfde probleem, omdat de doelhost het adres na NAT ziet en niet het oorspronkelijke.

Overlappende bereiken zijn de andere valkuil. Twee kantoren die beide 192.168.1.0/24 gebruiken, zijn niet in één beleidstabel te beschrijven zonder één kant te mappen, en een mapping is geen vervanging voor adressering die niet botst. Repareer het plan voordat je regels schrijft die je later moet ontwarren.

Bewijs een weigering, niet alleen een succes

Alleen de toegestane toepassing testen bewijst heel weinig, omdat een toegeeflijke regel ergens hogerop hetzelfde resultaat oplevert.

Bereik vanaf een gewoon filiaalapparaat de bedoelde dienst en bevestig dat de hele sessie werkt. Probeer daarna een bestemming die dicht moet blijven, zoals een administratieve poort op een server waar het filiaal niets mee te maken heeft, en lees de teller of logregel die hem heeft laten vallen. Het regelset uitschakelen om te controleren of het werkt, maakt de test ongeldig en laat de gateway open terwijl je kijkt.

Houd de lijst levend

Toepassingen verhuizen, en een regel die zijn toepassing overleeft, wordt een gat dat niemand bezit. Koppel de herzieningsdatum aan de rij en wijzig het bereik van de selector en de firewallregel in dezelfde onderhoudsstap wanneer een dienst van adres verandert.

Beperkingen op hostniveau blijven belangrijk achter de tunnel: de eigen firewall van de server hoort het filiaalbereik alleen te accepteren voor de dienst die hij publiceert. Twee lagen die overeenkomen zijn makkelijker te auditen dan één laag die volledig wordt vertrouwd.