Hypervisor i hjemmelaboratoriet er utilgængelig over VPN: hvor du skal kigge

Tunnelen kommer op, hypervisorens webside løber ud i tid, og klienten siger, at den er forbundet. Den kombination udelukker overraskende meget: VPN-håndtrykket virker, klienten har en adresse, og endepunktet er nåbart. Det, der er tilbage, er en kort liste af routing- og policyspørgsmål, og de har en naturlig rækkefølge. Arbejd dig gennem dem fra hypervisoren og udad i stedet for fra klienten og indad, fordi hypervisorens egen tilstand er det billigste at bekræfte.

Begynd med administrationssegmentet

Bekræft hypervisorens administrationsadresse og den tjeneste, der lytter på den, og bekræft, at siden indlæses fra en anden vært på det segment, før du diagnosticerer noget eksternt. En lokal test, der fejler, er ikke et VPN-problem, og det er en fem minutters kontrol, der sparer en time.

Så de to veje. VPN-klienten har brug for en rute til administrationsnetværket, hvilket normalt betyder, at klientens AllowedIPs eller skubbede ruter inkluderer det undernet. Hypervisoren eller dens standardgateway har brug for en returvej til klientadressepuljen, medmindre designet bevidst oversætter kilden på vej ind. Det er to separate fakta, og mangler en af dem, giver det samme timeout. Kontroller dem hver for sig: ip route get 192.168.10.20 på klienten og en optagelse på hypervisorværten, der viser, om pakken overhovedet ankom.

Tillad den faktiske fjernadministrator

Autorisation er et andet spørgsmål end nåbarhed. Brug gateway- og værtspolitik begrænset til de kilder og tjenester, der har brug for administrativ adgang. En gæste-VPN-konto, der har brug for én laboratorieapplikation, bør ikke dermed nå kontrolplanet, og en flad regel, der tillader hele tunnelundernettet, er hvordan det sker.

Hold hypervisorens egen godkendelse og certifikatkontroller slået til. En privat rute er ikke en grund til at klikke gennem en uventet identitetsadvarsel.

Advarslen er værd at behandle som et fund i stedet for en forhindring. Hvis certifikatet ikke matcher det navn, du brugte, er navnet forkert, eller også er tjenesten ikke den, du tror, og begge svar betyder mere på en administrationsflade end noget andet sted. Nå siden under det navn, certifikatet blev udstedt til, og lad DNS pege det navn på tunneladressen. Et privat navn, der opløses inkonsekvent mellem LAN og tunnel, er en almindelig årsag til certifikatklager, der ligner VPN-fejl.

Kontroller sekundære forbindelser

Nogle funktioner bruger forbindelser, som websiden ikke bruger. En konsolsession, en ISO-upload, en VNC- eller SPICE-proxy og en migreringskanal kan hver især bruge en anden port eller en anden værtadresse. Når siden indlæses, og en funktion fejler, så læs det pågældende produkts krav i stedet for at åbne hver port på værten.

At åbne alt er, hvordan en administrationsflade bliver en uadministreret en. Hver ekstra port er endnu en lytter, der skal holdes patchet, og en hypervisor eksponerer allerede nok af dem. Identificer den specifikke forbindelse, funktionen har brug for, bekræft, at den er nåbar gennem tunnelen, og lad resten være lukket. Hvis funktionen insisterer på en direkte forbindelse til en værtadresse, der ikke kan routes gennem din tunnel, er det en designbegrænsning, der skal omgås bevidst, ikke en grund til at videresende et område.

Behold en vej tilbage, før du rører netværket

Før du ændrer det virtuelle netværk, der bærer din egen VPN, så bekræft, at du har en lokal eller uafhængig vej tilbage.

Det betyder mest i et hjemmelaboratorium, fordi VPN-endepunktet ofte er en virtuel maskine på netop den hypervisor, du prøver at nå. Ændring af en virtuel switch, en bro eller en firewallregel eksternt kan fjerne den vej, du bruger, og sessionen kan overleve længe nok til at se det ske.

Test udefra laboratoriet i stedet for fra LAN, og verificer afvisningerne såvel som tilladelserne. Et netværk, der skal forblive unåeligt fra tunnelen, skal fortsat være unåeligt efter din ændring, og det er en separat påstand fra det, at administrationssiden indlæses. Skriv begge resultater ned, fordi det andet er det, der springes over, og det, der betyder noget, når laboratoriet vokser.

Den registrering, der skal beholdes, er kort: administrationsadressen og -tjenesten, den rute, hver side har brug for, de identiteter, der må nå den, og gendannelsesvejen. Det er nok til, at den næste person kan genskabe den fungerende tilstand uden at udlede den igen.

Hvis siden stadig løber ud i tid efter alt det, så optag på hypervisoren og led efter pakken, før du ændrer endnu en regel. En pakke, der aldrig ankommer, er et routing- eller firewallspørgsmål; en pakke, der ankommer og afvises, er et tjeneste- eller policyspørgsmål; en pakke, der ankommer og besvares, mens klienten venter, er et returvejsspørgsmål. strongSwan-dokumentationen om videresendelse dækker, hvordan en Linux-gateway videresender tunneltrafik til en intern vært. Tre optagelser slår endnu et gæt.