Så begränsar du åtkomsten mellan två VPN-anslutna kontor
En tunnel mellan platser är inte ömsesidigt förtroende. Bygg en matris över källa, mål och tjänst, verkställ den på dekrypterad trafik och bevisa också en avvisning.
En tunnel mellan platser svarar på en fråga, om de två kontoren kan utbyta paket, och lämnar den viktiga öppen: vilken filialenhet som får nå vilken central tjänst. Att behandla tunneln som ömsesidigt förtroende är hur en gästlaptop hamnar på samma väg som ekonomiservern. Lösningen är inte en bättre tunnel, utan en uttrycklig tillåtelselista som verkställs efter dekryptering. Den här guiden tar listan från definition till en bevisad avvisning.
Arbeta i den här ordningen och bredda inte tunnelrutten förrän policystegen nedan går igenom.
Skriv matrisen innan du rör gatewayen
En användbar rad namnger tre saker: en källgrupp, en målvärd eller ett tjänstenätverk, och det protokoll och den port som applikationen faktiskt använder. Filialen och datacentret är inte poster. Privat DNS och autentiseringstjänster förtjänar egna rader bara när applikationen inte kan fungera utan dem.
Gruppera källor efter roll och inte efter subnät-bekvämlighet: personal, gäster, administration. När alla tre delar ett platt LAN kan gatewayen inte skilja dem på nätverkslagret, så identitetskontroller eller segmentering måste komma först. Sätt sedan matrisen på pränt med en ägare och ett granskningsdatum på varje rad.
| Källa | Mål | Tjänst | Beslut |
|---|---|---|---|
| filialpersonal | bokningsapp 10.10.5.10 | TCP 443 | tillåt på gatewayen som dekrypterar |
| filialpersonal | VLAN för serveradministration | vilken som helst | implicit avvisning |
| gäst-Wi-Fi | valfritt centralt område | vilken som helst | avvisa före tunneln |
| administrativ hoppvärd | server-VLAN | TCP 22 och 3389 | tillåt med MFA, värdens brandvägg snävar in ytterligare |
Verkställ där paketen dekrypteras
Reglerna som tillåter IKE och ESP bygger bara den yttre tunneln. Den inre trafiken kommer i klartext på tunnelgränssnittet, och det är där tillåtelselistan hör hemma: en vidarebefordringskedja på enheten som dekrypterar, standarddrop, en regel per matrisrad. På Linux-gatewayer betyder det att vidarebefordran är påslagen och filterregler ligger på tunnelenheten, inte på den fysiska upplänken, vilket strongSwans guide för vidarebefordran förklarar.
Trafikväljare är ett routingbeslut, inte ett auktoriseringsbeslut. En bred väljare som täcker båda subnäten kan vara rätt för routingen medan brandväggen fortfarande bara tillåter TCP 443 till en värd. Väljaren förhandlas för tunneln och beskriver vad som får komma in i den, inte vad en viss enhet får använda. Bredda aldrig en brandväggsregel för att väljaren är bred.
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 DROPNAT och överlappande subnät ändrar reglerna
När filialens gateway översätter varje värd till en enda adress före tunneln, faller varje källbaserad rad samman i den enda adressen. Antingen slutar du översätta tunneltrafik, eller så accepterar du att regler måste vila på något annat, till exempel den ursprungliga källadressen som registrerades före översättningen. Den bortre änden har samma problem, eftersom målvärden ser adressen efter NAT och inte den ursprungliga.
Överlappande områden är den andra fällan. Två kontor som båda använder 192.168.1.0/24 kan inte beskrivas i en enda policytabell utan att mappa en sida, och en mappning ersätter inte adressering som inte kolliderar. Rätta planen innan du skriver regler som du senare måste nysta upp.
Bevisa en avvisning, inte bara en framgång
Att bara testa den tillåtna applikationen bevisar väldigt lite, eftersom en eftergiven regel någonstans högre upp ger samma resultat.
Från en vanlig filialenhet, nå den avsedda tjänsten och bekräfta att hela sessionen fungerar. Prova sedan ett mål som måste förbli stängt, till exempel en administrativ port på en server som filialen inte har något med att göra, och läs räknaren eller loggposten som släppte den. Att stänga av regeluppsättningen för att kontrollera om den fungerar gör testet ogiltigt och lämnar gatewayen öppen medan du tittar.
Håll listan levande
Applikationer flyttar på sig, och en regel som överlever sin applikation blir ett hål som ingen äger. Fäst granskningsdatumet vid raden och ändra väljarens omfattning och brandväggsregeln i samma underhållssteg när en tjänst byter adress.
Begränsningar på värdnivå spelar fortfarande roll bakom tunneln: serverns egen brandvägg bör bara acceptera filialens område för den tjänst den publicerar. Två lager som stämmer är lättare att granska än ett lager som litas på helt.