Ce trebuie consemnat pentru un VPN site-to-site: selectori și scop

La șase luni după ce un tunel a fost pus în funcțiune, o subrețea nouă nu mai corespunde politicii, iar singurul document din partajare spune VPN de birou. Aceasta este defecțiunea pe care o previne evidența selectorilor și este concretă: un set de adrese s-a schimbat, iar documentația nu. Să scrii corect evidența înseamnă să știi care dintre mai multe seturi de adrese descrii și să consemnezi setul pe care cealaltă parte îl aplică într-adevăr, nu pe cel pe care l-ai configurat.

Configurat nu este negociat

Într-un tunel IPsec bazat pe politici, fiecare parte propune selectori de trafic: intervale sursă și destinație pentru asociația copil. Partea care răspunde are voie să îngusteze această propunere, așa că asociația instalată poate acoperi mai puțin decât listează configurația. O evidență care copiază configurația descrie o intenție, nu scopul actual de protecție. Cele două diverg în liniște și nimic din pagina de stare a tunelului nu semnalează asta.

Păstrează ambele coloane, cu data la care le-ai observat. Selectorul configurat este ce ai intenționat; cel negociat este ce aplică nucleul chiar acum. Când diferă, această diferență explică o defecțiune surprinzătoare mult mai des decât o eroare de rutare.

O asociație nu reprezintă nici fiecare pereche configurată. Un tunel cu mai multe combinații de selectori poate ajunge cu mai multe asociații copil, iar o evidență care listează una dintre ele este un inventar parțial. Enumeră-le în loc să le rezumi.

Tunelurile bazate pe rute selectează altfel

Cu o interfață bazată pe rute, tabela de rutare decide ce intră în tunel, iar selectorii pot fi intenționat de largi. Este o construcție legitimă, nu o neglijență, iar evidența trebuie să o descrie ca atare. Notează ruta, interfața către care indică și politica de firewall care limitează serviciile accesibile. Scopul de protecție este larg intenționat, iar îngustarea o face scopul serviciilor.

Copierea unui șablon bazat pe politici pe un tunel bazat pe rute produce un document care descrie un mecanism ce nu este folosit de implementare. Următorul inginer caută apoi selectori care nu ar fi trebuit să existe niciodată și concluzionează că tunelul este configurat greșit, când de fapt este doar documentat prost.

Translatarea aparține aceleiași tabele

Când NAT prezintă celeilalte părți un interval diferit, consemnează prefixele original și tradus împreună. Notează etapa în care selectorii și regulile de acces le corespund, pentru că ordinea decide dacă partea îndepărtată va vedea vreodată adresa pe care ai scris-o. O tabelă cu doar unul dintre cele două intervale este mai rea decât lipsa unei tabele, fiindcă pare completă.

Acesta este detaliul care strică un tunel funcțional după o schimbare de NAT: selectorul corespunde în continuare prefixului original, cealaltă parte primește acum unul tradus, iar ruta sa de întoarcere indică o adresă care nu mai există. Nimic nu înregistrează o eroare în momentul în care cele două nu mai coincid.

DNS-ul privat aparține în același loc. Un nume care se rezolvă într-o adresă inutilizabilă din locația respectivă este o eroare de documentație cu un tichet de suport atașat, iar vina va cădea pe tunel.

Atașează cerința de serviciu

Un interval protejat nu este o listă de permisiuni. Notează ce servicii ar trebui să fie accesibile din ce sursă și cine deține aplicația din spatele lor. Aceste două câmpuri răspund la întrebări diferite, iar amestecarea lor face ca o revizuire de securitate să ajungă să dispute rutarea în loc de acces.

Apoi numește administratorul de rețea care întreține regula. Un inventar de selectori fără proprietar se învechește în liniște, iar învechit nu se poate distinge de greșit când tunelul cade la două dimineața. Proprietarul este și persoana care poate confirma că o modificare a fost intenționată.

Transformă evidența într-un plan de testare

Pentru fiecare cale necesară, alege un host sursă și unul destinație reprezentative și notează ruta, serviciul și gateway-ul de răspuns așteptate. Asta transformă documentul într-un plan de testare, nu într-o descriere. Citește asociația activă cu comanda de mai jos și compară-o cu linia negociată pe care ai scris-o.

swanctl --list-sas

Un schelet de cinci rânduri este de obicei suficient pentru ca evidența să rămână onestă. Versiunea de mai jos încape într-un tichet de modificare fără trunchiere:

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

Un ping doar până la gateway nu este testul de acceptanță. Nu exersează niciodată calea de tranzit, așa că poate trece în timp ce fiecare flux redirecționat eșuează. Testează de la un host de pe o parte la un serviciu de pe cealaltă și confirmă că răspunsul sosește prin tunel. Dacă trece doar pingul, evidența tocmai a găsit problema de redirecționare pe care trebuia să o prevină. Documentația strongSwan despre redirecționare explică modul în care selectorii, rutele și redirecționarea interacționează pe un nod Linux.