vpnc kontraŭ Check Point aŭ Nortel: kial ĝi haltas

La simptomo facile mislegiĝas: vpnc startas, petas la grupan pasvorton, poste restas ĉe trakta paŝo ĝis ĝi raportas, ke neniu respondo venas de la celo. Nenio en la eligo mencias la pordegan produkton, kaj la konto funkcias el retumilo, do la evidenta konkludo estas malĝusta pasvorto aŭ blokita pordo. En plej multaj el tiuj kazoj la pordego tute ne estas IPsec samulo, do la interŝanĝo neniam atingas la provon de legitimiloj. Tiu ŝablono indas esti testita antaŭ ol io ajn alia en la profilo ŝanĝiĝos.

Identigu la produkton antaŭ ol redakti alian profilkan kampon.

La malsukceso aspektas kiel malĝustaj legitimiloj

vpnc komencas sendante IKE al UDP 500 kaj, se NAT-traveturo estas proponita, al UDP 4500. Pordego, kiu finas SSL anstataŭ IPsec, respondas al neniu el ambaŭ, do la kliento reprovas kaj finfine rezignas kun ĝenerala eraro. Se la sama konto funkcias tra retumila portalo, kiu ŝargas malgrandan helpan aplikaĵon, tio estas forta indiko, ke la tunelo baziĝas sur SSL kaj la kliento faras la malĝustan demandon.

Malsukcesa provo ĉi tie diras nenion pri la uzantkonto, ĉar neniuj legitimiloj estis iam prezentitaj al la pordego.

Kontrolu, kiun protokolon la pordego proponas

Du minutoj da esplorado apartigas IPsec-samulon de SSL-portalo. Rulu ilin el la sama reto, kiun la kliento uzos, kaj legu, kiuj pordoj respondas, ne kiuj aperas en dokumento. Konservu la rezulton, ĉar tiuj samaj pordoj decidas, kiun klienton la pordega posedanto subtenu. Esploru el la klienta reto, ne el gastiganto apud la pordego.

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

Malfermita 443 kun alidirektado al ensaluta paĝo kaj silento ĉe 500 kaj 4500 indikas SSL VPN. Malfermitaj 500 kaj 4500 kun atestilo servata ĉe 443 sugestas IPsec-pordegon, kiu ankaŭ funkciigas retan interfacon, kio estas la kazo, por kiu vpnc estis konstruita.

La SSL Network Extender de Check Point kaj la Aventail-kliento de Nortel ambaŭ apartenas al la dua kategorio, kaj neniu el ili akceptas grupan sekreton de IKEv1.

Kion la profilo de vpnc povas esprimi kaj kion ne

Sub la kapuĉo vpnc rulas IKEv1 kontraŭ antaŭe kunhava grupa ŝlosilo, poste sendas la legitimilojn de la unuopa uzanto per XAuth. Ĉio en ĝia agorda dosiero apartenas al tiu interŝanĝo: pordego, grupa nomo, grupa sekreto, uzantnomo kaj uzanta pasvorto. Tiuj kampoj priskribas unu protokolon, kaj neniu kombino de ili povas igi la klienton paroli alian.

Tial plilarĝigi la ĉifran liston aŭ malŝalti atestilajn kontrolojn neniam riparas ĉi tiun klason de malsukceso. Tiuj ŝanĝoj malfortigas trakton, kiun la pordego ne aŭskultas.

Elekti la klienton, kiu kongruas kun la pordego

Por Check Point-pordego uzu la SNX-pakaĵon konstruitan por tiu pordega eldono, kiun la vendanto publikigas kune kun sia dokumentaro pri fora aliro. Pli malnovaj SNX-konstruoj ofte malsukcesas sur aktualaj distribuaĵoj, ĉar ili atendas 32-bit bibliotekojn, kiuj ne plu estas instalitaj, kaj fliki forlasitan pakaĵon kutime pli malbonas ol ruli la subtenatan klienton sur subtenata platformo.

Aventail-klientoj perdis subtenon antaŭ longe. Kie tia pordego ankoraŭ servas, la realismaj elektoj estas la retumila portalo, se la organizo ebligas ĝin, aŭ la subtenata kliento de la vendanto sur subtenata operaciumo.

Demandu la pordegan posedanton pri la produkto kaj versio, la kliento, kiun ili subtenas ĉe Linux, kaj ĉu entute ekzistas IPsec-profilo. Se ekzistas, petu la grupan identigilon kaj la grupan sekreton kiel apartajn erojn, ĉar ili ne estas la uzanta pasvorto, kaj interŝanĝita paro estas la alia ofta kaŭzo de malsukcesa tunelo. Kiam konekto fine sukcesas, notu, kiu protokolo estis traktita, por ke la sekva persono komencu de fakto anstataŭ ripeti la saman konjekton.