Waarom een werkende VPN toch een time-out krijgt op het antwoord
Dat een verzoek een privéserver bereikt, is maar de helft van de uitwisseling. Het antwoord moet de tunnelclient vinden via de bedoelde gateway, route of vertaling.
Het verzoek komt aan, de server logt het, en de client meldt nog steeds een time-out. Die combinatie betekent dat het antwoord de weg terug niet heeft gevonden, en dat is een van de weinige storingen die je van beide kanten tegelijk kunt bevestigen. Werk de controles op volgorde af en stop zodra een ervan faalt.
Begin bij waar het verzoek aankwam
Bevestig dat het pakket de dienst heeft bereikt voordat je iets anders onderzoekt. Een logregel aan de serverkant, een verbindingsteller of een toegestane capture aan de verre kant beantwoorden allemaal dezelfde vraag, en het ontbreken ervan stuurt je terug naar de tunnel in plaats van vooruit naar het antwoord. Dit is de controle die een doorstuurprobleem van een terugwegprobleem scheidt.
Als het verzoek nooit is aangekomen, stop dan hier. De tunnel, de routering naar het privéprefix of de toegangsregel is het onderwerp, en de antwoordroute is nog niet relevant. Noteer ook het bronadres dat de server zag. Het is ofwel het pooladres dat de client kreeg of een vertaald adres, en dat verschil bepaalt welke van de latere controles geldt.
Het antwoord heeft een route naar de pool nodig
Een client voor toegang op afstand krijgt meestal een adres uit een pool, en het privénetwerk heeft een route terug naar die pool nodig. Een server waarvan de standaardroute naar zijn eigen gateway wijst, geeft het pakket aan die gateway, die geen idee heeft waar de pool ligt, dus het antwoord sterft daar. De client ziet een time-out omdat er niets terugkwam, en dat is niet te onderscheiden van een verzoek dat nooit is vertrokken.
Controleer de route die de server voor het clientadres kiest, niet de route die hij voor zijn eigen subnet gebruikt. Die twee opzoekingen kunnen verschillende antwoorden geven, en de tweede is degene die hier telt. Vertaling is het alternatieve ontwerp en het verandert wat de server ziet. Het kan een terugweg vereenvoudigen, en het haalt ook het oorspronkelijke clientadres uit de logs van de server, wat elke regel of rapport beïnvloedt dat op dat veld is gebouwd.
Vergelijk de capture op de server met de capture op de gateway
Vergelijk wat de server verlaat met wat bij de gateway aankomt. Een capture op de uitgaande interface van de server en een capture op de tunnelgateway beantwoorden verschillende helften van de vraag, en de kloof ertussen lokaliseert het verlies.
ip route get 10.90.0.14
tcpdump -ni any host 10.90.0.14 and port 443
ip route show table all | grep 10.90.0.0| Where the reply stops | What it proves |
|---|---|
| Request in the server log, nothing on its outbound capture | The server picked a gateway that cannot reach the pool |
| Reply leaves the server but never shows up at the gateway | Loss on the LAN path, not on the tunnel |
| Reply reaches the gateway but not the client | Return translation or tunnel policy, not the server route |
Een verzoek dat de gateway zelf genereert is een slechte vervanging voor een clienttest, omdat het van een ander adres komt en andere regels tegenkomt. Daarom kunnen een geslaagde ping vanaf de gateway en een mislukt verzoek vanaf de client allebei waar zijn.
Als er meerdere routers op het pad zitten, controleer dan elk die een route naar de pool nodig heeft. Een site-naar-site-ontwerp vereist vaak dat het verre prefix op meer dan één apparaat bekend is, en de gateway zelf moet tussen de tunnel en het LAN doorsturen; de doorstuurnotities van strongSwan dekken de sysctl- en firewallkant daarvan.
Noteer de pool, het prefix en de eigenaar
Vier feiten horen in de notitie: de pool die de client kreeg, het privéprefix dat hij nodig had, de router die verantwoordelijk is voor het antwoord, en de vertaalregel als die bestaat. Daarmee is een latere gatewaywijziging een vergelijking en geen onderzoek.
Test daarna opnieuw met een gewone client en het echte applicatieaccount. Het uitbreiden van applicatierechten kan de terugweg van een pakket niet repareren, en een accountwijziging tijdens deze diagnose verwart de volgende vergelijking. Als het ontwerp op vertaling leunt, documenteer die dan waar de logs van de server worden gelezen. Wie in een auditspoor een onbekend bronadres ziet, zou de toewijzing niet opnieuw uit een ticket moeten hoeven ontdekken.