De ce copierea configurației serverului OpenVPN într-o sucursală eșuează
Un client de sucursală are nevoie de propria identitate, de un profil cu rol de client și de o rută pe care hubul o leagă de acel partener. Copierea fișierului serverului copiază rolul greșit.
Copierea configurației funcționale a serverului, schimbarea câtorva adrese și numirea acesteia profil de sucursală produce de obicei o conexiune. Acesta este cel mai rău rezultat, pentru că sucursala rulează apoi cu rolul greșit, expune material care nu ar trebui să părăsească hubul și lasă o asociere de rută pe care nimeni nu își amintește că a creat-o. Conexiunea ascunde trei probleme deodată, iar tunelul urcă înainte ca cineva să le verifice.
Tratarea sucursalei ca un partener cu identitate și rol de rețea proprii este ceea ce face profilul corect. Remedierea nu este o copie mai bună, iar restul acestei pagini tratează ce ar trebui să păstreze de fapt un client.
Două roluri care arată ca un singur fișier
În modul TLS cele două părți au sarcini complementare. O parte ascultă, păstrează certificatul și cheia serverului și decide ce clienți se pot conecta. Cealaltă parte inițiază, verifică ascultătorul și își prezintă propria identitate.
Un fișier de server conține directive care nu au sens pe un client: o adresă de legare și un port pentru ascultare, un bazin de adrese de distribuit și adesea o listă de împingere pentru setările pe care clienții ar trebui să le primească. Copierea lor într-o sucursală produce un dispozitiv care încearcă să fie ascultător și client în același timp.
Cheia privată este partea care contează cel mai mult. Un client nu trebuie să poarte niciodată cheia privată a serverului și nu are nevoie nici de cheia de semnare a CA. Un certificat CA este material public de încredere; cheia de semnare aparține locului unde se emit certificatele.
Ce trebuie să conțină un profil de sucursală
Un profil de sucursală are nevoie de punctul final la distanță și transport, de identitatea de server de încredere, de certificatul și cheia sucursalei proprii, precum și de rutele și setările DNS pe care sucursala le cere cu adevărat. Nimic altceva nu este obligatoriu.
Păstrați identitatea sucursalei separată pentru fiecare locație. Două sucursale care împart un certificat înseamnă că revocarea uneia o dezactivează pe cealaltă, iar jurnalele hubului nu le pot distinge. O identitate pe locație este ceea ce face să funcționeze atât urma de audit, cât și povestea revocării.
Fiți atenți la fluxurile de lucru ale echipamentelor. Pachetul Client Export al pfSense generează profiluri pentru contextele Remote Access eligibile, iar lista sa de servere include doar servere configurate într-un mod Remote Access. Un server sit-la-sit dintr-un alt mod nu apare, iar acea absență este informație, nu o invitație de a copia secretele serverului.
Dacă echipamentul nu exportă profilul de care aveți nevoie, folosiți fluxul de lucru documentat pentru client sit-la-sit sau construiți profilul din exemplul acceptat al versiunii instalate. Exportați o copie de siguranță a serverului în sucursală doar dacă planul este restaurarea unui server, ceea ce nu este cazul. O copie poartă și material privat al hubului, așa că mutarea ei într-o sucursală este o decizie privind manipularea cheilor, nu un transfer de fișier. Păstrați-o pe hub și generați identitatea clientului acolo unde se emit certificatele.
Asocierea dintre partener și rețea este separată
Un client de sucursală care se conectează cu succes tot nu poate trece trafic pentru LAN-ul său până când hubul nu știe că acest partener deține acel prefix. Asocierea respectivă trăiește pe hub, legată de identitatea clientului, și este separată de ruta proprie a sucursalei către rețelele la distanță. Fără ea, gazdele sucursalei par accesibile în statisticile tunelului și nu sunt accesibile în practică. Jurnalul hubului este locul unde se confirmă dacă asocierea a fost aplicată.
Adăugarea unei rute în sistemul de operare al hubului nu este același lucru cu a-i spune lui OpenVPN care client deține prefixul. Fără asocierea pe client, pachetul ajunge la interfața tunelului și este aruncat pentru că niciun partener nu revendică destinația.
Pe partea sucursalei, nevoia corespunzătoare este o rută către rețelele pe care trebuie să le atingă, plus un router LAN care știe să returneze traficul către sucursală. Proprietatea pe partea serverului și rutele de destinație pe partea clientului sunt obiecte distincte, iar un tunel funcțional dovedește doar primul salt. Notați ambele în notele de predare ale sucursalei, pentru că următorul inginer va găsi doar una dintre ele.
A dovedi că sucursala este partenerul la care vă gândiți
Verificați identitatea înainte de a verifica traficul. Jurnalul hubului ar trebui să arate numele comun al certificatului sucursalei, iar adresa primită de client ar trebui să corespundă bazinului sau atribuirii fixe pe care o intenționați. Dacă jurnalul arată alt nume, profilul poartă identitatea altcuiva.
Apoi verificați asocierea trimițând o cerere de la o gazdă din sucursală către o resursă de pe partea hubului și confirmați că reușește cu adresa de sursă așteptată. Testați o destinație pe care sucursala nu trebuie să o atingă și confirmați că eșuează, pentru că o rută permisivă care funcționează din întâmplare nu este același lucru cu o politică corectă.
În final, revocați identitatea sucursalei și confirmați că conexiunea eșuează în timp ce certificatul hubului și alte locații continuă să funcționeze. Dacă revocarea strică hubul, rolurile și identitățile au fost partajate undeva, iar aceasta este constatarea care merită dusă înapoi în proiectare.
O sucursală terminată este cea cu identitate documentată, profil doar pentru client, o asociere între partener și rețea pe hub și o cale de întoarcere testată. Inversarea textului într-un fișier de server nu vă oferă niciuna dintre ele.