Adrese de tunel statice în pfSense: preferință sau rezervare?

Două modele arată similar pe hârtie și se comportă foarte diferit atunci când o regulă depinde de ele. Unul tastează o adresă într-o suprascriere de client și are încredere în adresă ca identitate. Celălalt închide complet admiterea dinamică, astfel încât un punct final fie are o alocare unică, fie nu se conectează. Doar al doilea transformă o adresă într-un element de politică pe care îl puteți apăra, iar diferența merită înțeleasă înainte de a scrie o singură regulă de firewall.

Ce promite de fapt o adresă de suprascriere

O suprascriere specifică clientului poartă opțiuni per client, inclusiv o adresă de tunel preferată. Netgate descrie acea adresă ca o preferință, nu ca o rezervare, ceea ce înseamnă că poolul dinamic nu renunță la adresă pentru nimeni altcineva.

De obicei este în regulă. O coliziune este rară, iar clientul primește de obicei ce a cerut, ceea ce este suficient pentru confort și nu este suficient pentru autorizare. Confortul și autorizarea sunt cerințe diferite, iar doar una dintre ele supraviețuiește unei coliziuni.

Cu topologia de subrețea, câmpul preia adresa clientului împreună cu masca rețelei serverului, astfel încât o adresă din interiorul unui tunel 10.90.0.0/24 se scrie ca 10.90.0.10/24.

Nimic din toate acestea nu rezervă numărul. Un client a cărui suprascriere nu se potrivește, sau o sesiune duplicată, poate ajunge în altă parte a poolului, iar o regulă bazată pe adresă descrie atunci pe cineva care nu este acolo.

Închideți calea dinamică cu un implicit delimitat

Alternativa este un server exclusiv static: fiecare punct final admis are propria identitate și propria adresă unică, iar nimic altceva nu intră.

Implementarea înseamnă o suprascriere DEFAULT limitată la acel singur server, cu blocarea conexiunilor activată. Un client fără o suprascriere potrivită nu poate atunci reveni la admiterea dinamică obișnuită. Acea singură linie este ce transformă o preferință într-un set închis.

Domeniul de aplicare contează. O suprascriere implicită aplicată fiecărei instanțe VPN de pe mașină va bloca tuneluri fără legătură, iar acea defecțiune arată ca un serviciu stricat, nu ca o decizie de politică. Legați-o de singurul server al cărui model de admitere îl schimbați. Apoi notați domeniul în jurnalul de modificări, deoarece următoarea persoană nu își va aminti de ce tunel aparține.

Auditați apoi întregul set permis. Blocarea implicită nu repară o suprascriere numită lăsată fără adresă, iar acel punct final pur și simplu nu se va conecta fără un indiciu evident despre motiv.

Potriviți identitatea pe care serverul o folosește cu adevărat

O suprascriere se potrivește cu ceva. Pe un server care potrivește nume comune de certificate, numele suprascrierii trebuie să fie acel nume comun, nu numele afișat al persoanei. Copiați-l din certificat, nu din lista de conturi.

Un server configurat să folosească numele de utilizator drept nume comun potrivește pe o cheie complet diferită, iar o suprascriere numită după certificat nu se va declanșa niciodată. Citiți setarea în loc să o deduceți din ce arată lista de conturi.

Păstrați factorii de autentificare suplimentari pe care îi cere implementarea. Un model de adrese închis schimbă cine se poate conecta și ce adresă primește; nu înlocuiește verificarea certificatului sau al doilea factor.

Scrieți regulile de acces după ce harta este solidă

Odată ce harta de la identitate la adresă este închisă, regulile pot referi adrese fără a pretinde că sunt persoane. Un alias care grupează punctele finale ale unei persoane poate ajunge la un serviciu anume, în timp ce alt alias ajunge la altceva. Aliasul devine obiectul verificabil, iar adresa devine un detaliu de implementare în interiorul lui.

Păstrați destinațiile și porturile explicite. Permiterea întregii rețele locale din întregul pool de tuneluri este exact modelul pe care acest exercițiu urma să îl înlocuiască.

Citiți regulile flotante, de grup și de interfață în ordinea lor reală de evaluare, deoarece o trecere largă anterioară anulează una îngustă ulterioară. Dezactivarea redirecționării interne între clienți menține traficul între parteneri la granița unde sunt verificate aceste reguli. O regulă care există doar pe hârtie nu este aplicare.

Testați cazurile negative

Exersați patru conexiuni noi: un punct final numit, unul fără nicio suprascriere, un serviciu care ar trebui să fie accesibil și unul care nu ar trebui. Punctul final neenumerat este cazul important, deoarece el este cel pe care modelul există să îl oprească. Dacă se conectează, blocarea implicită nu își face treaba.

Verificați IPv6 separat, deoarece o politică de adrese IPv4 nu spune nimic despre un al doilea stack. Apoi confirmați că aplicația autorizează în continuare utilizatorul, deoarece o adresă de tunel este un fapt de rețea, nu o dovadă a cine este la tastatură. Ambele verificări aparțin notei de acceptare.

În sfârșit, planificați migrarea. Suprascrierile noi și regulile înguste nu schimbă retroactiv sesiunile deja stabilite, așa că stările existente trebuie să expire sau să fie șterse în mod deliberat.