Wat om vir 'n site-tot-site-VPN te dokumenteer: selektore en omvang
'n Selektorrekkord moet sê wat elke peer sien. Gekonfigureerde prefikse, onderhandelde assosiasies, vertaling en diens-eienaarskap hoort almal daarin.
Ses maande nadat 'n tonnel in diens geneem is, hou 'n nuwe subnet op om by die beleid te pas, en die enigste dokument op die deel sê net kantoor-VPN. Dit is die fout wat 'n selektorrekkord voorkom, en dit is spesifiek: 'n adresversameling het verander terwyl die papierwerk dieselfde gebly het. Om die rekord reg te skryf, beteken dat jy moet weet watter van die verskillende adresversamelings jy beskryf, en dat jy die een opteken wat die peer werklik afdwing, eerder as die een wat jy gekonfigureer het.
Gekonfigureer is nie onderhandel nie
In 'n beleidgebaseerde IPsec-tonnel stel elke kant verkeersselektore voor: bron- en bestemmingreekse vir die kindassosiasie. Die responder mag daardie voorstel vernou , so die geïnstalleerde assosiasie kan minder dek as wat die konfigurasie lys. 'n Rekord wat die konfigurasie kopieer, beskryf dus 'n bedoeling, nie die huidige beskermingsomvang nie. Die twee wyk stilweg uiteen, en niks op die tonnelstatusbladsy wys daarop nie.
Hou albei kolomme, met die datum waarop jy hulle waargeneem het. Die gekonfigureerde selektor is wat jy bedoel het; die onderhandelde een is wat die kernel nou tans afdwing. Wanneer hulle verskil, verduidelik daardie verskil 'n verrassende fout baie meer dikwels as wat 'n routeringsfout dit doen.
Een assosiasie verteenwoordig ook nie elke gekonfigureerde paar nie. 'n Tonnel met verskeie selektorkombinasies kan op verskeie kindassosiasies uitloop, en 'n rekord wat net een daarvan lys, is 'n gedeeltelike inventaris. Lys hulle eerder as om hulle op te som.
Roetegebaseerde tonnele kies anders
Met 'n roetegebaseerde koppelvlak besluit die routeringstabel wat die tonnel binnegaan, en die selektore kan doelbewus breed wees. Dit is 'n wettige ontwerp eerder as slordigheid, en die rekord moet dit as sodanig beskryf. Skryf die roete neer, die koppelvlak waarheen dit wys, en die firewall-beleid wat beperk watter dienste bereikbaar is. Die beskermingsomvang is doelbewus wyd, en die diensomvang doen die vernouing.
'n Beleidgebaseerde sjabloon op 'n roetegebaseerde tonnel kopieer, lewer 'n dokument wat 'n meganisme beskryf wat die ontplooiing nie gebruik nie. Die volgende ingenieur soek dan na selektore wat nooit bedoel was om daar te wees nie, en kom tot die gevolgtrekking dat die tonnel verkeerd gekonfigureer is, terwyl dit net sleg gedokumenteer is.
Vertaling hoort in dieselfde tabel
Wanneer NAT 'n ander reeks aan die peer voorhou, teken die oorspronklike en die vertaalde prefikse saam op. Let op die stadium waarin selektore en toegangsreëls by hulle pas, want die volgorde bepaal of die ander kant ooit die adres sien wat jy neergeskryf het. 'n Tabel met net een van die twee reekse is slegter as geen tabel nie, want dit lyk volledig.
Dit is die besonderheid wat 'n werkende tonnel ná 'n NAT-verandering breek: die selektor pas steeds by die oorspronklike prefiks, die peer ontvang nou 'n vertaalde een, en sy terugroete wys na 'n adres wat nie meer bestaan nie. Niks teken 'n fout aan op die oomblik wanneer die twee ophou ooreenstem nie.
Privaat DNS hoort op dieselfde plek. 'n Naam wat na 'n adres oplos wat van die betrokke site af onbruikbaar is, is 'n dokumentasiefout met 'n ondersteuningskaartjie aangeheg, en dit sal die tonnel verwyt word.
Heg die diensvereiste aan
'n Beskermde reeks is nie 'n toestemmingslys nie. Skryf neer watter dienste van watter bron af bereikbaar moet wees, en wie eienaar is van die toepassing daar agter. Daardie twee velde beantwoord verskillende vrae, en om hulle te verwar, is hoe 'n sekuriteitsondersoek uiteindelik oor routering in plaas van toegang stry.
Noem dan die netwerkadministrateur wat die reël instand hou. 'n Selektorinventaris sonder 'n eienaar verouder stilweg, en verouderd is nie te onderskei van verkeerd wanneer die tonnel om twee in die oggend breek nie. Die eienaar is ook die persoon wat kan bevestig dat 'n verandering doelbewus was.
Maak die rekord 'n toetsplan
Kies vir elke vereiste pad 'n verteenwoordigende bron- en bestemmingsgasheer en let op die verwagte roete, diens en antwoordpoort. Dit maak die dokument 'n toetsplan eerder as 'n beskrywing. Lees die lewendige assosiasie terug met die opdrag hieronder, en vergelyk dit met die onderhandelde ry wat jy neergeskryf het.
swanctl --list-sas
'n Vyflyn-skelet is gewoonlik genoeg om die rekord eerlik te hou. Die weergawe hieronder pas in 'n veranderingstoken sonder om afgekap te word:
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
'n Slegs-poort-ping is nie die aanvaardingstoets nie. Dit oefen nooit die deurgangspad nie, so dit kan slaag terwyl elke aangestuurde vloei misluk. Toets van 'n gasheer aan die een kant na 'n diens aan die ander kant en bevestig dat die antwoord deur die tonnel aankom. As net die ping slaag, het die rekord pas die aanstuurprobleem gevind waarvoor dit geskryf is. strongSwan-dokumentasie oor aansturing verduidelik hoe selektore, roetes en aansturing op 'n Linux-peer inmekaar werk.