vpnc mot Check Point eller Nortel: hvorfor det henger

Symptomet er lett å lese feil: vpnc starter, spør etter gruppepassordet og blir så stående på et forhandlingstrinn til det rapporterer at det ikke kommer svar fra målet. Ingenting i utdataene nevner gatewayens produkt, og kontoen virker fra en nettleser, så den åpenbare slutningen er et feil passord eller en blokkert port. I de fleste av disse tilfellene er gatewayen ikke en IPsec-peer i det hele tatt, så utvekslingen kommer aldri langt nok til å teste legitimasjon. Det mønsteret er verdt å teste før noe annet i profilen endres.

Identifiser produktet før du redigerer et annet profilfelt.

Feilen ser ut som feil legitimasjon

vpnc begynner med å sende IKE til UDP 500 og, hvis NAT-traversering tilbys, til UDP 4500. En gateway som avslutter SSL i stedet for IPsec svarer ikke på noen av dem, så klienten prøver på nytt og gir til slutt opp med en generisk feil. Hvis samme konto virker gjennom en nettleserportal som laster en liten hjelpeapplikasjon, er det et sterkt hint om at tunnelen er SSL-basert og at klienten spør om feil ting.

Et mislykket forsøk her sier ingenting om brukerkontoen, fordi det aldri ble lagt fram legitimasjon for gatewayen.

Sjekk hvilken protokoll gatewayen tilbyr

To minutters undersøkelse skiller en IPsec-peer fra en SSL-portal. Kjør dem fra samme nettverk som klienten skal bruke, og les hvilke porter som svarer i stedet for hvilke som står i et dokument. Ta vare på resultatet, for de samme portene avgjør hvilken klient gatewayens eier bør støtte. Undersøk fra klientnettet og ikke fra en vert ved siden av gatewayen.

nc -zvu gw.example.com 500
nc -zvu gw.example.com 4500
nc -zvt gw.example.com 443
curl -sI https://gw.example.com/ | head -5
openssl s_client -connect gw.example.com:443 -servername gw.example.com </dev/null | head -20

En åpen 443 med omdirigering til en påloggingsside og stillhet på 500 og 4500 peker på en SSL VPN. Åpne 500 og 4500 med et sertifikat som serveres på 443 tyder på en IPsec-gateway som også kjører et webgrensesnitt, og det er tilfellet vpnc ble bygget for.

Check Points SSL Network Extender og Nortels Aventail-klient hører begge til den andre kategorien, og ingen av dem godtar en IKEv1-gruppehemmelighet.

Hva vpnc-profilen kan og ikke kan uttrykke

Under panseret kjører vpnc IKEv1 mot en på forhånd delt gruppenøkkel og sender deretter den enkelte brukerens legitimasjon gjennom XAuth. Alt i konfigurasjonsfilen hører til den utvekslingen: gateway, gruppenavn, gruppehemmelighet, brukernavn og brukerpassord. Disse feltene beskriver én protokoll, og ingen kombinasjon av dem kan få klienten til å snakke en annen.

Derfor retter aldri utvidelse av chifferserien eller deaktivering av sertifikatkontroller denne typen feil. Disse endringene svekker en forhandling som gatewayen ikke lytter etter.

Velge klienten som passer gatewayen

For en Check Point-gateway bruker du SNX-pakken som er bygget for den gatewayversjonen, som leverandøren publiserer sammen med dokumentasjonen for fjernaksess. Eldre SNX-bygg feiler ofte på gjeldende distribusjoner fordi de forventer 32-bit-biblioteker som ikke lenger er installert, og å lappe en forlatt pakke er vanligvis verre enn å kjøre den støttede klienten på en støttet plattform.

Aventail-klienter mistet støtten for lenge siden. Der en slik gateway fortsatt er i drift, er de realistiske valgene nettleserportalen hvis organisasjonen aktiverer den, eller leverandørens støttede klient på et støttet operativsystem.

Spør gatewayens eier om produktet og versjonen, klienten de støtter på Linux, og om det i det hele tatt finnes en IPsec-profil. Hvis det gjør det, be om gruppeidentifikatoren og gruppehemmeligheten som separate elementer, fordi de ikke er brukerpassordet, og et ombyttet par er den andre vanlige årsaken til en mislykket tunnel. Når en tilkobling endelig lykkes, noter hvilken protokoll som ble forhandlet, slik at neste person starter fra et faktum i stedet for å gjenta samme gjetning.