vpnc mot Check Point eller Nortel: varför det hänger sig

Symtomet är lätt att läsa fel: vpnc startar, frågar efter grupplösenordet och står sedan kvar på ett förhandlingssteg tills det rapporterar att inget svar kommer från målet. Inget i utdata nämner gatewayens produkt, och kontot fungerar från en webbläsare, så den uppenbara slutsatsen är ett fel lösenord eller en blockerad port. I de flesta av dessa fall är gatewayen inte alls en IPsec-peer, så utbytet kommer aldrig tillräckligt långt för att testa inloggningsuppgifter. Det mönstret är värt att testa innan något annat i profilen ändras.

Identifiera produkten innan du redigerar ett annat profilfält.

Felet ser ut som fel inloggningsuppgifter

vpnc börjar med att skicka IKE till UDP 500 och, om NAT-traversering erbjuds, till UDP 4500. En gateway som avslutar SSL i stället för IPsec svarar inte på någon av dem, så klienten försöker igen och ger till slut upp med ett allmänt fel. Om samma konto fungerar via en webbläsarportal som laddar en liten hjälpapplikation är det ett starkt tecken på att tunneln bygger på SSL och att klienten ställer fel fråga.

Ett misslyckat försök här säger ingenting om användarkontot, eftersom inga inloggningsuppgifter någonsin presenterades för gatewayen.

Kontrollera vilket protokoll gatewayen erbjuder

Två minuters undersökning skiljer en IPsec-peer från en SSL-portal. Kör dem från samma nätverk som klienten ska använda, och läs vilka portar som svarar i stället för vilka som står i ett dokument. Spara resultatet, för samma portar avgör vilken klient gatewayens ägare bör stödja. Undersök från klientnätet och inte från en värd bredvid 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 öppen 443 med en omdirigering till en inloggningssida och tystnad på 500 och 4500 pekar på en SSL VPN. Öppna 500 och 4500 med ett certifikat som serveras på 443 tyder på en IPsec-gateway som också kör ett webbgränssnitt, och det är fallet vpnc byggdes för.

Check Points SSL Network Extender och Nortels Aventail-klient tillhör båda den andra kategorin, och ingen av dem accepterar en IKEv1-grupphemlighet.

Vad vpnc-profilen kan och inte kan uttrycka

Under huven kör vpnc IKEv1 mot en fördelad gruppnyckel och skickar sedan den enskilda användarens inloggningsuppgifter via XAuth. Allt i dess konfigurationsfil hör till det utbytet: gateway, gruppnamn, grupphemlighet, användarnamn och användarlösenord. De fälten beskriver ett enda protokoll, och ingen kombination av dem kan få klienten att tala ett annat.

Därför åtgärdar aldrig en utökad chifferlista eller avstängda certifikatkontroller den här typen av fel. De ändringarna försvagar en förhandling som gatewayen inte lyssnar på.

Välja klienten som passar gatewayen

För en Check Point-gateway använder du SNX-paketet som är byggt för den gatewayversionen, som leverantören publicerar tillsammans med sin dokumentation för fjärråtkomst. Äldre SNX-byggen misslyckas ofta på nuvarande distributioner eftersom de förväntar sig 32-bit-bibliotek som inte längre är installerade, och att lappa ett övergivet paket är vanligtvis sämre än att köra den stödda klienten på en stödd plattform.

Aventail-klienter förlorade stödet för länge sedan. Där en sådan gateway fortfarande är i drift är de realistiska valen webbläsarportalen om organisationen aktiverar den, eller leverantörens stödda klient på ett stött operativsystem.

Fråga gatewayens ägare om produkten och versionen, klienten de stöder på Linux, och om det överhuvudtaget finns en IPsec-profil. Om det gör det, be om gruppidentifieraren och grupphemligheten som separata poster, för de är inte användarlösenordet och ett omkastat par är den andra vanliga orsaken till en misslyckad tunnel. När en anslutning till slut lyckas, notera vilket protokoll som förhandlades fram, så att nästa person utgår från ett faktum i stället för att upprepa samma gissning.