Hypervisor i heimelaben er utilgjengeleg over VPN: kvar du skal sjå
Tunnelen er oppe, og sida til hypervisoren blir ikkje lasta. Kontroller administrasjonssegmentet, returruta til klientpoolen og deretter vertspolicyen.
Tunnelen kjem opp, nettsida til hypervisoren går ut på tid, og klienten seier at han er tilkopla. Den kombinasjonen utelukkar overraskande mykje: VPN-handtrykket verkar, klienten har ei adresse, og endepunktet er nåbart. Det som står att, er ei kort liste med rutings- og policyspørsmål, og dei har ein naturleg rekkjefølgje. Arbeid deg gjennom dei frå hypervisoren og utover i staden for frå klienten og innover, fordi tilstanden til hypervisoren sjølv er det billegaste å stadfeste.
Byrj med administrasjonssegmentet
Stadfest administrasjonsadressa til hypervisoren og tenesta som lyttar på henne, og stadfest at sida blir lasta frå ein annan vert i det segmentet før du diagnostiserer noko eksternt. Ein lokal test som feilar er ikkje eit VPN-problem, og det er ein kontroll på fem minutt som sparer ein time.
Så dei to vegane. VPN-klienten treng ei rute til administrasjonsnettet, noko som vanlegvis betyr at AllowedIPs til klienten eller skyvne ruter inkluderer det undernettet. Hypervisoren, eller standardgatewayen hans, treng ein returveg til klientadressepoolen, med mindre designet medvite omset kjelda på veg inn. Det er to separate fakta, og manglar ein av dei, gir det same tidsavbrot. Kontroller dei kvar for seg: ip route get 192.168.10.20 på klienten, og eit opptak på hypervisorverten som viser om pakken i det heile kom fram.
Tillat den faktiske fjernadministratoren
Autorisasjon er eit anna spørsmål enn nåbarheit. Bruk gateway- og vertspolicy avgrensa til kjeldene og tenestene som treng administrasjonstilgang. Ein gjest-VPN-konto som treng éin labapplikasjon, bør ikkje dermed nå kontrollplanet, og ei flat regel som slepp inn heile tunnelundernettet, er korleis det skjer.
Hald autentiseringa til hypervisoren sjølv og sertifikatkontrollane på. Ei privat rute er ikkje grunn til å klikke gjennom ei uventa identitetsåtvaring.
Åtvaringa er verd å handsame som eit funn og ikkje som ein hindring. Viss sertifikatet ikkje samsvarar med namnet du brukte, er anten namnet feil eller tenesta er ikkje den du trur, og begge svara betyr meir på eit administrasjonsgrensesnitt enn nokon annan stad. Nå sida under namnet sertifikatet vart utstedt til, og la DNS peike det namnet til tunneladressa. Eit privat namn som blir løyst inkonsistent mellom LAN og tunnel er ein vanleg årsak til sertifikatklager som ser ut som VPN-feil.
Kontroller sekundære tilkoplingar
Nokre funksjonar brukar tilkoplingar som nettsida ikkje brukar. Ei konsolløkt, ei ISO-opplasting, ein VNC- eller SPICE-proxy og ein migrasjonskanal kan kvar bruke ein annan port eller ei anna vertsadresse. Når sida blir lasta og ein funksjon feilar, les kravet til det produktet i staden for å opne kvar port på verten.
Å opne alt er korleis eit administrasjonsgrensesnitt blir eit uadministrert eit. Kvar ekstra port er ein lyttar til som må haldast oppdatert, og ein hypervisor eksponerer allereie nok av dei. Identifiser den konkrete tilkoplinga funksjonen treng, stadfest at ho er nåbar gjennom tunnelen, og la resten vere lukka. Viss funksjonen insisterer på ei direkte tilkopling til ei vertsadresse som ikkje kan rutast gjennom tunnelen din, er det ei designavgrensing som må omgåast medvite, ikkje ein grunn til å videresende eit område.
Hald ein veg tilbake før du rører nettet
Før du endrar det virtuelle nettet som ber din eigen VPN, må du stadfeste at du har ein lokal eller uavhengig veg tilbake.
Dette betyr mest i ein heimelab, fordi VPN-endepunktet ofte er ein virtuell maskin på nettopp den hypervisoren du prøver å nå. Å endre ein virtuell svitsj, ei bru eller ei brannmurregel eksternt kan fjerne vegen du brukar, og økta kan overleve lenge nok til å sjå det skje.
Test utanfrå laben i staden for frå LAN, og stadfest avvisingane like godt som løyva. Eit nett som skal halde fram med å vere unåbart frå tunnelen, skal framleis vere det etter endringa di, og det er ei eiga påstand frå at administrasjonssida blir lasta. Skriv ned begge resultata, fordi det andre er det som blir hoppa over, og det som betyr noko når laben veks.
Registreringa som skal haldast er kort: administrasjonsadressa og -tenesta, ruta kvar side treng, identitetane som har lov til å nå henne, og gjenopprettingsvegen. Det er nok til at neste person kan gjenskape den fungerande tilstanden utan å utleie han på nytt.
Viss sida framleis går ut på tid etter alt dette, ta eit opptak på hypervisoren og sjå etter pakken før du endrar ei regel til. Ein pakke som aldri kjem fram er eit rutings- eller brannmurspørsmål; ein pakke som kjem fram og blir avvist er eit teneste- eller policyspørsmål; ein pakke som kjem fram og blir svara medan klienten ventar er eit returvegspørsmål. strongSwan-dokumentasjonen om videresending dekkjer korleis ein Linux-gateway videresender tunneltrafikk til ein intern vert. Tre opptak slår éi gjetting til.