Wat je vastlegt voor een site-to-site-VPN: selectors en scope
Een selectorrecord moet zeggen wat elke peer ziet. Geconfigureerde prefixen, onderhandelde associaties, vertaling en service-eigenaarschap horen er allemaal in.
Zes maanden nadat een tunnel in gebruik is genomen, past een nieuw subnet niet meer bij het beleid en het enige document op de share zegt kantoor-VPN. Dat is de storing die een selectorrecord voorkomt, en hij is concreet: een adressenset veranderde terwijl de papieren dat niet deden. Het record goed schrijven betekent weten welke van meerdere adressensets je beschrijft, en de set vastleggen die de peer werkelijk afdwingt in plaats van de set die je hebt geconfigureerd.
Geconfigureerd is niet onderhandeld
In een op beleid gebaseerde IPsec-tunnel stelt elke kant traffic selectors voor: bron- en bestemmingsreeksen voor de child-associatie. De responderende kant mag dat voorstel versmallen, dus de geïnstalleerde associatie kan minder omvatten dan de configuratie vermeldt. Een record dat de configuratie kopieert beschrijft een bedoeling, niet de huidige beschermingsscope. De twee lopen stil uiteen, en niets op de statuspagina van de tunnel wijst daarop.
Houd beide kolommen bij, met de datum waarop je ze hebt waargenomen. De geconfigureerde selector is wat je bedoelde; de onderhandelde is wat de kernel nu afdwingt. Wanneer ze verschillen, verklaart dat verschil een verrassende storing veel vaker dan een routeringsfout.
Eén associatie vertegenwoordigt ook niet elk geconfigureerd paar. Een tunnel met meerdere selectorcombinaties kan op meerdere child-associaties uitkomen, en een record dat er één vermeldt is een gedeeltelijke inventaris. Noem ze allemaal in plaats van ze samen te vatten.
Op routes gebaseerde tunnels kiezen anders
Met een op routes gebaseerde interface bepaalt de routeringstabel wat de tunnel in gaat en kunnen de selectors bewust breed zijn. Dat is een legitiem ontwerp en geen slordigheid, en het record moet dat zo beschrijven. Schrijf de route op, de interface waarnaar hij wijst, en het firewallbeleid dat beperkt welke diensten bereikbaar zijn. De beschermingsscope is met opzet breed, en de servicescope doet het versmallen.
Een op beleid gebaseerd sjabloon op een op routes gebaseerde tunnel kopiëren levert een document op dat een mechanisme beschrijft dat de uitrol niet gebruikt. De volgende engineer zoekt dan naar selectors die er nooit hadden moeten zijn, en concludeert dat de tunnel verkeerd is geconfigureerd terwijl hij alleen slecht is gedocumenteerd.
Vertaling hoort in dezelfde tabel
Wanneer NAT de peer een andere reeks presenteert, leg dan de oorspronkelijke en de vertaalde prefixen samen vast. Noteer in welke fase de selectors en toegangsregels ermee overeenkomen, want de volgorde bepaalt of de andere kant ooit het adres ziet dat je hebt opgeschreven. Een tabel met slechts één van de twee reeksen is erger dan geen tabel, omdat hij compleet lijkt.
Dit is het detail dat een werkende tunnel na een NAT-wijziging breekt: de selector komt nog overeen met het oorspronkelijke prefix, de peer ontvangt nu een vertaald prefix, en zijn retourroute wijst naar een adres dat niet meer bestaat. Niets logt een fout op het moment dat de twee niet meer overeenkomen.
Privé-DNS hoort op dezelfde plek. Een naam die naar een adres resolvet dat vanaf de betreffende locatie onbruikbaar is, is een documentatiefout met een supportticket eraan vast, en het zal de tunnel worden verweten.
Voeg de servicevereiste toe
Een beschermde reeks is geen machtigingenlijst. Schrijf op welke diensten vanaf welke bron bereikbaar horen te zijn, en wie de applicatie erachter bezit. Die twee velden beantwoorden verschillende vragen, en ze door elkaar halen is hoe een beveiligingsreview uiteindelijk over routering discussieert in plaats van over toegang.
Noem vervolgens de netwerkbeheerder die de regel onderhoudt. Een selectorinventaris zonder eigenaar veroudert stil, en verouderd is niet te onderscheiden van fout wanneer de tunnel om twee uur 's nachts uitvalt. De eigenaar is ook degene die kan bevestigen dat een wijziging opzettelijk was.
Maak van het record een testplan
Kies voor elk vereist pad een representatieve bron- en bestemmingshost en noteer de verwachte route, dienst en antwoordgateway. Dat maakt van het document een testplan in plaats van een beschrijving. Lees de actieve associatie terug met het onderstaande commando, en vergelijk die met de onderhandelde regel die je hebt opgeschreven.
swanctl --list-sas
Een skelet van vijf regels is meestal genoeg om het record eerlijk te houden. De versie hieronder past zonder afkappen in een wijzigingsticket:
sites: office <-> dc1
configured selector: 10.10.0.0/16 <-> 10.20.0.0/16
negotiated selector: 10.10.4.0/22 <-> 10.20.0.0/16
translated range: 172.16.4.0/22 -> 10.10.4.0/22
service and owner: erp:443 / finance-netops
Alleen een ping naar de gateway is niet de acceptatietest. Hij oefent het transitpad nooit, dus hij kan slagen terwijl elke doorgestuurde stroom faalt. Test vanaf een host aan de ene kant naar een dienst aan de andere en bevestig dat het antwoord via de tunnel binnenkomt. Als alleen de ping slaagt, heeft het record net het doorstuurprobleem gevonden dat het moest voorkomen. De strongSwan-documentatie over doorsturen legt uit hoe selectors, routes en doorsturen op een Linux-peer samenspelen.