Hipervizorul laboratorului de acasă inaccesibil prin VPN: unde să te uiți

Tunelul se ridică, pagina web a hipervizorului expiră, iar clientul spune că este conectat. Această combinație exclude surprinzător de mult: handshake-ul VPN funcționează, clientul are o adresă, iar punctul final este accesibil. Ce rămâne este o listă scurtă de întrebări de rutare și politică, și au o ordine naturală. Parcurge-le de la hipervizor spre exterior, nu de la client spre interior, pentru că starea hipervizorului însuși este cel mai ieftin lucru de confirmat.

Începe cu segmentul de administrare

Confirmă adresa de administrare a hipervizorului și serviciul care ascultă pe ea, și confirmă că pagina se încarcă de pe o altă gazdă din acel segment înainte de a diagnostica ceva de la distanță. Un test local care eșuează nu este o problemă de VPN și este o verificare de cinci minute care economisește o oră.

Apoi cele două căi. Clientul VPN are nevoie de o rută către rețeaua de administrare, ceea ce înseamnă de obicei că AllowedIPs clientului sau rutele împinse includ acea subrețea. Hipervizorul, sau gateway-ul său implicit, are nevoie de o cale de întoarcere către pool-ul de adrese al clienților, dacă proiectarea nu traduce în mod deliberat sursa la intrare. Sunt două fapte separate, iar lipsa oricăruia produce același timp de expirare. Verifică-le separat: ip route get 192.168.10.20 pe client, și o captură pe gazda hipervizorului care arată dacă pachetul a ajuns.

Permite administratorul la distanță real

Autorizarea este o întrebare separată de accesibilitate. Folosește politică de gateway și de gazdă limitată la sursele și serviciile care au nevoie de acces de administrare. Un cont VPN de oaspete care are nevoie de o aplicație de laborator nu ar trebui să ajungă astfel la planul de administrare, iar o regulă plată care admite întreaga subrețea a tunelului este modul în care se întâmplă asta.

Lasă activă autentificarea hipervizorului însuși și verificările de certificat. O rută privată nu este un motiv să treci printr-un avertisment de identitate neașteptat.

Merită tratat avertismentul ca o constatare și nu ca un obstacol. Dacă certificatul nu corespunde numelui folosit, fie numele este greșit, fie serviciul nu este cel la care te gândești, iar ambele răspunsuri contează mai mult într-o interfață de administrare decât oriunde altundeva. Ajunge la pagină sub numele pentru care a fost emis certificatul și lasă DNS-ul să indice acel nume către adresa tunelului. Un nume privat care se rezolvă inconsistent între LAN și tunel este o cauză comună a reclamațiilor despre certificate care arată ca defecțiuni VPN.

Verifică conexiunile secundare

Unele funcții folosesc conexiuni pe care pagina web nu le folosește. O sesiune de consolă, o încărcare ISO, un proxy VNC sau SPICE și un canal de migrare pot folosi fiecare un port diferit sau o adresă de gazdă diferită. Când pagina se încarcă și o funcție eșuează, citește cerința acelui produs în loc să deschizi fiecare port pe gazdă.

Deschiderea tuturor este modul în care o interfață de administrare devine neadministrată. Fiecare port suplimentar este încă un ascultător de întreținut, iar un hipervizor expune deja destule. Identifică conexiunea specifică de care are nevoie funcția, confirmă că este accesibilă prin tunel și lasă restul închis. Dacă funcția insistă pe o conexiune directă la o adresă de gazdă care nu poate fi rutată prin tunelul tău, aceea este o constrângere de proiectare de ocolit în mod deliberat, nu un motiv pentru a redirecționa un interval.

Păstrează o cale de întoarcere înainte de a atinge rețeaua

Înainte de a schimba rețeaua virtuală care transportă propriul tău VPN, confirmă că ai o cale de întoarcere locală sau independentă.

Asta contează cel mai mult într-un laborator de acasă, pentru că punctul final al VPN este adesea o mașină virtuală chiar pe hipervizorul pe care încerci să îl atingi. Schimbarea unui switch virtual, a unui bridge sau a unei reguli de firewall de la distanță poate elimina calea pe care o folosești, iar sesiunea poate supraviețui suficient pentru a vedea asta întâmplându-se.

Testează din afara laboratorului, nu din LAN, și verifică refuzurile la fel ca permisiunile. O rețea care trebuie să rămână inaccesibilă din tunel trebuie să rămână așa și după modificarea ta, iar aceasta este o afirmație separată de încărcarea paginii de administrare. Notează ambele rezultate, pentru că al doilea este cel omis și cel care contează când laboratorul crește.

Înregistrarea de păstrat este scurtă: adresa și serviciul de administrare, ruta de care are nevoie fiecare parte, identitățile permise să ajungă și calea de recuperare. Este suficient pentru ca următoarea persoană să reproducă starea funcțională fără a o deduce din nou.

Dacă pagina încă expiră după toate acestea, capturează pe hipervizor și caută pachetul înainte de a schimba altă regulă. Un pachet care nu ajunge niciodată este o întrebare de rutare sau firewall; un pachet care ajunge și este refuzat este o întrebare de serviciu sau politică; un pachet care ajunge și primește răspuns în timp ce clientul așteaptă este o întrebare de cale de întoarcere. Documentația strongSwan despre forwarding explică modul în care un gateway Linux trimite traficul tunelului către o gazdă internă. Trei capturi bat încă o presupunere.