Refuz de geolocalizare în Firebox: găsiți mai întâi etapa de intrare VPN
Regula care blochează un client VPN este adesea politica de intrare, nu regula de acces a utilizatorului. Șase verificări care găsesc etapa reală înainte de a schimba ceva.
Cineva din altă țară nu se poate conecta, iar primul instinct este să ne uităm la regula care acordă acces la resursele interne. Acea regulă rulează după admitere, deci nu poate fi ceea ce respinge tunelul. Etapa care blochează se află undeva pe calea de intrare, iar Firebox are mai mult de o cale de intrare în funcție de serviciul VPN. Faceți verificările în ordine și opriți-vă imediat ce una dintre ele explică refuzul.
Verificarea 1: numiți serviciul de intrare
Pentru Mobile VPN cu SSL, Access Portal și BOVPN peste TLS, intrarea de intrare este politica WatchGuard SSLVPN. Aplicați acolo restricția dorită, pe serviciul configurat efectiv, în loc să o deduceți dintr-o regulă de acces a utilizatorului care rulează mai târziu.
IPsec urmează o altă cale. Politica IPSec încorporată permite traficul IPsec extern către Firebox pentru serviciile de sucursală și VPN mobil aplicabile și are prioritate față de o politică IPSec creată manual. Dacă clientul dvs. este IKEv2, sunteți pe acea a doua cale, iar politica SSLVPN este irelevantă.
A greși aici este după-amiaza cea mai des irosită din acest domeniu: să editați o politică ce nu vede niciodată pachetul și apoi să concluzionați că restricția nu funcționează.
Verificarea 2: citiți refuzul, nu teoria
Faceți o singură încercare permisă și controlată și corelați patru lucruri: adresa de sursă publică a clientului, serviciul de intrare atins, politica care s-a potrivit și orice motiv de refuz din jurnal. Ghidul de depanare IKEv2 al WatchGuard notează că geolocalizarea și tratarea implicită a pachetelor pot refuza traficul înainte de admiterea politicii încorporate, ceea ce înseamnă că refuzul pe care îl vedeți poate numi o etapă la care nu v-ați gândit.
Clasificarea țării urmează sursa de rețea observată. Un utilizator în roaming, un NAT superior sau o altă cale aprobată pot schimba ceea ce vede Firebox, așa că confirmați adresa, nu descrierea utilizatorului despre unde se află. Cereți adresa publică pe care o vede clientul și comparați-o cu sursa din jurnalul Firebox. Când diferă, clasificarea urmează o cale pe care nimeni nu a menționat-o.
Verificarea 3: politica încorporată este încă proprietarul?
Dacă o politică IPSec manuală pare ignorată, verificați dacă cea încorporată este încă activă. O regulă manuală umbrită de o regulă încorporată cu prioritate mai mare și o regulă manuală care este singura admitere sunt configurații diferite cu o interfață cu aspect identic.
Decideți care ar trebui să dețină calea. Dacă este politica manuală, cea încorporată trebuie dezactivată pentru acel trafic, și acolo începe următoarea verificare.
Verificarea 4: planificați înlocuirea înainte de dezactivare
Dezactivarea politicii IPSec încorporate elimină admiterea acesteia pentru serviciile VPN afectate. Aceasta include tuneluri de sucursală la care poate nu vă gândiți în timp ce reparați conexiunea unui singur utilizator mobil.
Planificați mai întâi înlocuirea completă: ce servicii au nevoie de admitere, ce intervale de sursă primesc și cum veți administra aparatul dacă schimbarea merge prost. Păstrați deschisă o cale independentă de administrare și recuperare, deoarece o greșeală aici poate elimina tunelul pe care l-ați folosi pentru a o repara. Notați pașii de recuperare în registrul de modificări, inclusiv cum ajungeți la aparat dacă calea VPN a dispărut. Apoi testați reînnoirea, nu doar prima conexiune.
Conectivitatea activă și renegocierea ulterioară pot depinde ambele de admitere. O modificare care funcționează pentru sesiunea testată și eșuează la următoarea schimbare de cheie este un rezultat clasic al înlocuirii admiterii fără testarea reînnoirii.
Verificarea 5: păstrați identitatea separată de locație
Geolocalizarea adaugă context unei decizii de intrare. Nu stabilește cine este utilizatorul și nu ar trebui să înlocuiască verificările de identitate ale gateway-ului, autorizarea contului sau MFA.
Dacă cerința de afaceri este doar utilizatori aprobați din locuri aprobate, aveți nevoie de ambele controale. O regulă de locație care admite o țară întreagă nu înlocuiește autentificarea, iar un utilizator autentificat într-o țară blocată este o chestiune de politică, nu un defect.
Verificarea 6: consemnați-o și verificați ambele căi
Notați serviciul, politica de intrare, domeniul de locație dorit, excepțiile și responsabilul de recuperare. Apoi testați calea mobilă și cel puțin o cale de site după modificare, astfel încât restricția să rămână legată de serviciul pentru care a fost proiectată.
În final, recitiți refuzul cu care ați început. Dacă s-a schimbat dintr-un refuz de locație într-o eroare de autentificare sau autorizare, problema de intrare este rezolvată și acum se vede alta. Ghidul WatchGuard despre refuzurile IKEv2 este referința pentru ordinea etapelor descrisă mai sus.