Dispozitivele locale dispar pe VPN: trei defecțiuni separate

O imprimantă care dispare din lista de dispozitive când VPN-ul pornește poate răspunde în continuare la adresa sa. Lista este populată de descoperire, numele poate veni de la un resolver, iar serviciul în sine este atins printr-un socket, iar cele trei pot eșua independent. Compararea a ceea ce funcționează la fiecare nivel vă spune ce funcție să schimbați. Dacă activați mai întâi toate excepțiile de acces local, eliminați dovezile.

Aceasta este diferența dintre un dispozitiv care lipsește și un dispozitiv care pur și simplu nu este anunțat.

Descoperirea, numele și accesibilitatea sunt trei niveluri

Protocoalele de descoperire se bazează pe multicast sau broadcast, iar acestea nu traversează implicit un tunel rutat, motiv pentru care un dispozitiv poate dispărea dintr-o listă rămânând perfect accesibil. Rezolvarea numelor este un al doilea nivel: un VPN poate schimba resolverul, iar un nume la care răspundea anterior rețeaua locală poate fi acum rezolvat în altă parte sau deloc. Accesibilitatea este al treilea: o rută, o regulă de firewall și un serviciu care ascultă. Fiecare nivel se poate strica în timp ce celelalte două sunt în regulă.

Testați-le de jos în sus. O singură verificare a accesibilității face separarea evidentă: nc -vz 192.168.1.20 443 fie reușește, ceea ce înseamnă că traseul și serviciul sunt în regulă și numele este suspectul, fie eșuează, ceea ce mută întrebarea la rutare și politică. Apoi întrebați numele. Primul eșec pe care îl întâlniți este nivelul la care trebuie lucrat, iar nivelurile de deasupra nu îl pot compensa.

Întrebați mai întâi adresa, apoi numele de gazdă

Dacă adresa răspunde și numele nu, problema este rezolvarea și nu rutarea. Un client VPN care își instalează propriul resolver poate schimba care server răspunde la numele locale, iar unul care nu redirecționează domeniul local lasă numele fără răspuns. Dacă și adresa eșuează, problema este traseul: o rută implicită prin tunel, o blocare a traficului local pe partea clientului sau o regulă de firewall care permite doar interfața fizică.

Dacă ambele funcționează, dar descoperirea automată nu, dispozitivul pur și simplu nu se anunță prin tunel. Acesta este comportamentul așteptat pentru descoperirea bazată pe multicast, nu o eroare de configurare. Adăugarea dispozitivului după adresă este de obicei soluția onestă.

Ce schimbă de fapt comutatorul de acces local

O setare de acces la rețeaua locală permite de obicei traficului către subrețeaua conectată direct să ocolească tunelul și face lucruri diferite în clienți diferiți. Nu configurează redirecționarea către un birou la distanță și nu schimbă firewall-ul gazdei sau permisiunile aplicației în sine. De asemenea, nu face o subrețea suprapusă lipsită de ambiguitate. Citiți documentația clientului despre ce acoperă setarea înainte de a o activa pe scară largă.

O excepție îngustă pentru un singur dispozitiv de încredere este mai bună decât o permisiune generală, mai ales într-o rețea de oaspeți unde blocarea poate fi intenționată. O adresă privată nu este o verificare de identitate, așa că alegerea depinde de rețeaua în care vă aflați.

Când rețelele se suprapun

Dacă rețeaua de acasă și cea de la distanță folosesc același interval, rutarea devine ambiguă și nici comutatorul de acces local, nici o excepție nu o rezolvă. Două servicii la aceeași adresă nu pot fi ambele accesate, iar care câștigă depinde de specificitatea rutei și de ordine, nu de intenție. Soluția este planificarea adreselor, nu o setare a clientului. Verificați intervalele înainte de a petrece o seară cu imprimanta.

Pentru un dispozitiv din spatele gateway-ului la distanță, operatorul deține redirecționarea, politica gazdei și ruta de întoarcere. O casetă locală din client nu poate furniza niciuna dintre ele, iar a o cere este mai productiv decât a experimenta cu comutatoare.

Notați ce nivel a eșuat și ce ați schimbat. Următorul dispozitiv va eșua într-unul din aceleași trei locuri.