Hypervisor i hjemmelaben er utilgjengelig over VPN: hvor du skal se

Tunnelen kommer opp, hypervisorens nettside går ut på tid, og klienten sier at den er tilkoblet. Den kombinasjonen utelukker overraskende mye: VPN-håndtrykket virker, klienten har en adresse, og endepunktet er nåbart. Det som gjenstår, er en kort liste med ruting- og policyspørsmål, og de har en naturlig rekkefølge. Arbeid deg gjennom dem fra hypervisoren og utover i stedet for fra klienten og innover, fordi hypervisorens egen tilstand er det billigste å bekrefte.

Begynn med administrasjonssegmentet

Bekreft hypervisorens administrasjonsadresse og tjenesten som lytter på den, og bekreft at siden lastes fra en annen vert i det segmentet før du diagnostiserer noe eksternt. En lokal test som feiler er ikke et VPN-problem, og det er en fem minutters kontroll som sparer en time.

Så de to veiene. VPN-klienten trenger en rute til administrasjonsnettet, noe som vanligvis betyr at klientens AllowedIPs eller pushede ruter inkluderer det undernettet. Hypervisoren, eller standardgatewayen dens, trenger en returvei til klientadressepoolen, med mindre designet bevisst oversetter kilden på vei inn. Det er to separate fakta, og mangler én av dem, gir det samme tidsavbrudd. Kontroller dem hver for seg: ip route get 192.168.10.20 på klienten, og en opptak på hypervisorverten som viser om pakken i det hele tatt kom frem.

Tillat den faktiske fjernadministratoren

Autorisasjon er et annet spørsmål enn nåbarhet. Bruk gateway- og vertspolicy begrenset til kildene og tjenestene som trenger administrasjonstilgang. En gjest-VPN-konto som trenger én labapplikasjon, bør ikke dermed nå kontrollplanet, og en flat regel som slipper inn hele tunnelundernettet, er hvordan det skjer.

Hold hypervisorens egen autentisering og sertifikatkontroller på. En privat rute er ikke grunn til å klikke gjennom en uventet identitetsadvarsel.

Advarselen er verdt å behandle som et funn og ikke som en hindring. Hvis sertifikatet ikke samsvarer med navnet du brukte, er enten navnet feil eller tjenesten er ikke den du tror, og begge svarene betyr mer på et administrasjonsgrensesnitt enn noe annet sted. Nå siden under navnet sertifikatet ble utstedt til, og la DNS peke det navnet til tunneladressen. Et privat navn som løses inkonsekvent mellom LAN og tunnel er en vanlig årsak til sertifikatklager som ser ut som VPN-feil.

Kontroller sekundære tilkoblinger

Noen funksjoner bruker tilkoblinger som nettsiden ikke bruker. En konsolløkt, en ISO-opplasting, en VNC- eller SPICE-proxy og en migreringskanal kan hver bruke en annen port eller en annen vertsadresse. Når siden lastes og en funksjon feiler, les kravet til det produktet i stedet for å åpne hver port på verten.

Å åpne alt er hvordan et administrasjonsgrensesnitt blir et uadministrert et. Hver ekstra port er en lytter til som må holdes oppdatert, og en hypervisor eksponerer allerede nok av dem. Identifiser den konkrete tilkoblingen funksjonen trenger, bekreft at den er nåbar gjennom tunnelen, og la resten være lukket. Hvis funksjonen insisterer på en direkte tilkobling til en vertsadresse som ikke kan rutes gjennom tunnelen din, er det en designbegrensning som må omgås bevisst, ikke en grunn til å videresende et område.

Behold en vei tilbake før du rører nettverket

Før du endrer det virtuelle nettverket som bærer din egen VPN, må du bekrefte at du har en lokal eller uavhengig vei tilbake.

Dette betyr mest i en hjemmelab, fordi VPN-endepunktet ofte er en virtuell maskin på nettopp den hypervisoren du prøver å nå. Å endre en virtuell svitsj, en bro eller en brannmurregel eksternt kan fjerne veien du bruker, og økten kan overleve lenge nok til å se det skje.

Test utenfra laben i stedet for fra LAN, og verifiser avvisningene like godt som tillatelsene. Et nettverk som skal forbli unåelig fra tunnelen, skal fortsatt være det etter endringen din, og det er en egen påstand fra at administrasjonssiden lastes. Skriv ned begge resultatene, fordi det andre er det som hoppes over, og det som betyr noe når laben vokser.

Registreringen som skal beholdes er kort: administrasjonsadressen og -tjenesten, ruten hver side trenger, identitetene som har lov til å nå den, og gjenopprettingsveien. Det er nok til at neste person kan gjenskape den fungerende tilstanden uten å utlede den på nytt.

Hvis siden fortsatt går ut på tid etter alt dette, ta et opptak på hypervisoren og se etter pakken før du endrer en regel til. En pakke som aldri ankommer er et ruting- eller brannmurspørsmål; en pakke som ankommer og avvises er et tjeneste- eller policyspørsmål; en pakke som ankommer og besvares mens klienten venter er et returveispørsmål. strongSwan-dokumentasjonen om videresending dekker hvordan en Linux-gateway videresender tunneltrafikk til en intern vert. Tre opptak slår én gjetning til.