Hypervisor in het homelab niet bereikbaar via VPN: waar je moet kijken

De tunnel komt op, de webpagina van de hypervisor loopt in een time-out en de client zegt dat hij verbonden is. Die combinatie sluit verrassend veel uit: de VPN-handshake werkt, de client heeft een adres en het eindpunt is bereikbaar. Wat overblijft is een korte lijst met routing- en beleidsvragen, en die hebben een natuurlijke volgorde. Werk ze van de hypervisor naar buiten af in plaats van van de client naar binnen, want de eigen toestand van de hypervisor is het goedkoopst om te bevestigen.

Begin bij het beheersegment

Bevestig het beheeradres van de hypervisor en de dienst die daarop luistert, en bevestig dat de pagina laadt vanaf een andere host in dat segment voordat u iets op afstand diagnosticeert. Een lokale test die mislukt is geen VPN-probleem, en het is een controle van vijf minuten die een uur bespaart.

Dan de twee paden. De VPN-client heeft een route naar het beheernetwerk nodig, wat meestal betekent dat de AllowedIPs van de client of de gepushte routes dat subnet bevatten. De hypervisor, of zijn standaardgateway, heeft een terugweg naar de clientadrespool nodig, tenzij het ontwerp de bron bij binnenkomst bewust vertaalt. Dat zijn twee afzonderlijke feiten en het ontbreken van een van beide geeft dezelfde time-out. Controleer ze apart: ip route get 192.168.10.20 op de client, en een capture op de hypervisorhost die laat zien of het pakket überhaupt aankwam.

Sta de daadwerkelijke remote-beheerder toe

Autorisatie is een andere vraag dan bereikbaarheid. Gebruik gateway- en hostbeleid beperkt tot de bronnen en diensten die beheer toegang nodig hebben. Een gast-VPN-account dat één labapplicatie nodig heeft, zou daardoor niet het beheervlak moeten bereiken, en een platte regel die het hele tunnelsubnet toestaat is hoe dat gebeurt.

Houd de eigen authenticatie van de hypervisor en de certificaatcontroles aan. Een privéroute is geen reden om door een onverwachte identiteitswaarschuwing te klikken.

De waarschuwing is het waard als bevinding te behandelen en niet als obstakel. Als het certificaat niet overeenkomt met de naam die u gebruikte, is ofwel de naam verkeerd of is de dienst niet degene die u denkt, en beide antwoorden wegen op een beheerinterface zwaarder dan waar dan ook. Bereik de pagina onder de naam waarvoor het certificaat is uitgegeven, en laat DNS die naam naar het tunneladres wijzen. Een privénaam die inconsistent tussen het LAN en de tunnel wordt opgelost is een veelvoorkomende oorzaak van certificaatklachten die op VPN-fouten lijken.

Controleer secundaire verbindingen

Sommige functies gebruiken verbindingen die de webpagina niet gebruikt. Een consolesessie, een ISO-upload, een VNC- of SPICE-proxy en een migratiekanaal kunnen elk een andere poort of een ander hostadres gebruiken. Wanneer de pagina laadt en één functie faalt, lees dan de eis van dat product in plaats van elke poort op de host te openen.

Alles openen is hoe een beheerinterface een onbeheerde interface wordt. Elke extra poort is weer een listener die bijgehouden moet worden, en een hypervisor toont er al genoeg. Identificeer de specifieke verbinding die de functie nodig heeft, bevestig dat die via de tunnel bereikbaar is, en laat de rest dicht. Als de functie aandringt op een directe verbinding met een hostadres dat niet via uw tunnel routeerbaar is, is dat een ontwerpbeperking die bewust omzeild moet worden, geen reden om een bereik door te sturen.

Houd een weg terug voordat u het netwerk aanraakt

Voordat u het virtuele netwerk wijzigt dat uw eigen VPN draagt, bevestigt u dat u een lokale of onafhankelijke weg terug hebt.

Dit telt het zwaarst in een homelab, omdat het VPN-eindpunt vaak een virtuele machine is op precies de hypervisor die u probeert te bereiken. Een virtuele switch, een bridge of een firewallregel op afstand wijzigen kan de weg verwijderen die u gebruikt, en de sessie kan lang genoeg overleven om dat te zien gebeuren.

Test van buiten het lab in plaats van vanaf het LAN, en verifieer de weigeringen net zo goed als de toestemmingen. Een netwerk dat ontoegankelijk moet blijven vanaf de tunnel moet dat ook na uw wijziging blijven, en dat is een aparte bewering van het laden van de beheerpagina. Schrijf beide resultaten op, want het tweede is degene die wordt overgeslagen en degene die telt wanneer het lab groeit.

Het record dat u bewaart is kort: het beheeradres en de -dienst, de route die elke kant nodig heeft, de identiteiten die er mogen komen en het herstelpad. Dat is genoeg voor de volgende persoon om de werkende toestand te reproduceren zonder die opnieuw af te leiden.

Loopt de pagina na dat alles nog in een time-out, maak dan een capture op de hypervisor en zoek het pakket voordat u nog een regel wijzigt. Een pakket dat nooit aankomt is een routing- of firewallvraag; een pakket dat aankomt en wordt geweigerd is een dienst- of beleidsvraag; een pakket dat aankomt en wordt beantwoord terwijl de client wacht is een terugwegvraag. De strongSwan-documentatie over doorsturen behandelt hoe een Linux-gateway tunnelverkeer naar een interne host doorstuurt. Drie captures verslaan nog een gok.