Itugma ang Linux VPN client sa protocol ng lumang appliance

Apat na pamilya ng protocol ang sumasaklaw sa halos bawat appliance na nakalagay pa sa rack, at bawat isa ay nabibigo nang iba sa Linux. Ang mga nailathalang port at naka-configure na proposal ng kabilang dulo ang nagpapasya sa package mo, hindi ang distribution na nagkataong pinapatakbo mo. Ang mag-install ng nabanggit sa isang forum post at pagkatapos ay mag-edit hanggang may kumonekta ay ang paraan kung paano nawawala ang isang hapon. Basahin ang appliance, mag-install bilang pangalawa, i-verify bilang pangatlo.

Itala ang inilalathala ng kabilang dulo

Isulat ang protocol, mga port at authentication na inaasahan ng appliance bago magbukas ng package manager. Apat na pamilya ang sumasaklaw sa karamihan ng lumang kagamitan, at ang talahanayan sa ibaba ang buong pasya sa isang screen.

Ang manual at ang sariling firewall rules ng appliance ay mas mapagkakatiwalaan kaysa sa pangalan ng protocol sa login page nito. Ang appliance na nag-aanunsyo ng IPsec ay maaaring IKEv1 lang ang sinasabi, at ang firmware release na walang nag-apply ay maaaring siyang magdagdag ng IKEv2 sa huli. Kumpirmahin ang data path at ang setup port, dahil dito nagkakaiba ang lumang kagamitan at modernong network. Ang magkamali sa hakbang na ito ay nangangahulugang i-debug ang client mo laban sa feature na hindi kailanman nagkaroon ang kabilang dulo.

PPTP: patunayan ang GRE bago i-edit ang pppd

Ang PPTP sa Linux ay hindi daemon na sinisimulan mo kundi tawag sa pppd, at ang mga parameter ng koneksyon ay nasa pinangalanang peer file na binabasa ng pppd kapag tinawag ito. Binabalot pa rin ito ng mga distribution, kahit ginagawa itong hindi angkop ng mga kilalang kahinaan ng protocol para sa anumang sensitibo, kaya itago ito nang mahigpit para sa appliance na walang ibang inaalok. Bantayan ang GRE habang nakikipag-usap ang client, gamit ang maikling capture sa halip na hula. Ang pagkabigong pinakanauubos ng oras ay hindi authentication kundi ang nawawalang data path.

pppd call branch-office
tcpdump -ni any proto gre -c 5

Kung natapos ang setup at hindi kailanman nagdadala ng trapiko ang link, hinala ang GRE path bago hawakan ang credentials. Kailangan ng cloud security groups ng malinaw na panuntunan para sa protocol 47, at may mga network na ganap na hinaharangan ito nang walang nakikitang error. Subukan mula sa network na talagang gagamitin mo, hindi mula sa lab na pinapayagan ang lahat.

L2TP/IPsec: isang tugmang proposal ang tatalo sa sampung pagtatangka

Basahin ang log ng daemon sa halip na ang desktop dialog, dahil pinagsasama ng dialog ang ilang magkakaibang pagkabigo sa isang mensahe. Ang error na NO_PROPOSAL_CHOSEN ay kabilang sa unang yugto: nag-alok ang client ng encryption, hash o Diffie-Hellman group na hindi tatanggapin ng server. Ilahad kung ano ang sinusuportahan ng appliance at sumulat ng isang tugmang proposal, dahil kadalasang mas mabagal na ibinibigay ng random na kombinasyon ang parehong error. Sa desktop, ang praktikal na client ay ang NetworkManager L2TP plugin na may strongSwan o Libreswan sa ilalim.

Ang proposal string na isang bagay para sa desktop plugin ay maaaring ibang bagay para sa daemon na pinagkakatiwalaan nito ng trabaho, kaya panatilihing angkop ang syntax sa layer na ine-edit mo. Kung humihingi rin ang appliance ng tunnel secret, hiwalay na yugto iyon sa IPsec key. Kumpirmahin kung alin sa dalawa ang tinatanong ng interface bago mag-type ng anuman dito.

IKEv1 na agresibo kasama ng XAuth, at ang kaso ng portal

Ang endpoint na FortiGate-style ay karaniwang gusto ng agresibong mode kasama ng XAuth at address sa configured mode, na maaaring hindi ilahad ng graphical plugin. Kaya ito ng native daemon, at ang bloke sa ibaba ay ang hugis ng configuration na iyon, hindi isang kumpletong file. Tingnan ang kasalukuyang dokumentasyon ng vendor para sa mga halaga ng proposal.

conn branch
    keyexchange=ikev1
    aggressive=yes
    leftauth=psk
    leftauth2=xauth
    leftsourceip=%config
    right=203.0.113.10

Gumamit ang mga lumang release ng strongSwan ng xauth=client kung saan ginagamit ng bersyon 5 ang leftauth2=xauth, kaya ang kopyang snippet ay maaaring mabigo sa syntax pa lang. Para sa TLS portal, ang openconnect na nagsasalita ng AnyConnect protocol ay humahawak sa Cisco at karamihan ng rebranded na produkto, at kailangan nito ng TUN device at mga pribilehiyo para i-configure ito. Ipasa ang address ng portal nang eksakto kung paano ito ipinapakita ng browser, kasama ang anumang path na inaasahan ng appliance, pagkatapos ay tingnan ang itinalagang address bago subukan ang anuman sa likod nito. Ang paggawa ng interface nang maaga ay nag-aalis ng isang klase ng sorpresa sa setup.

sudo ip tuntap add dev tun0 mode tun
sudo openconnect --protocol=anyconnect vpn.example.com

Kumonekta, pagkatapos ay i-verify sa takdang pagkakasunod-sunod

Magpatakbo ng eksaktong isang VPN manager sa isang pagkakataon, dahil mag-aagawan ng ruta at DNS ang isang NetworkManager profile at isang daemon na sinimulan sa kamay. Ibaba ang profile bago subukan ang manual na koneksyon, at kumpirmahing walang lumang tunnel interface na natira. Pagkatapos ay i-verify sa ganitong pagkakasunod-sunod: address ng tunnel, ruta patungo sa nag-iisang internal host na kailangan mo, name resolution, at sa huli isang tunay na request. Ang berdeng icon ay nagpapatunay ng authentication at wala nang iba.

ip -4 addr show tun0
ip route get 10.20.30.10
getent hosts app.internal

Kung mabigo ang isang hakbang, huminto doon sa halip na subukan ang susunod, dahil walang itinuturo sa iyo ang pagkabigo ng DNS sa ilalim ng sirang ruta. Mag-imbak ng kopya ng gumaganang profile bago mag-eksperimento, dahil madaling mawala ang naburang connection file at mahirap itong itayo muli. Itago ang mga halaga ng proposal sa parehong nota ng modelo ng appliance at bersyon ng firmware, dahil ang notang iyon ang pagkakaiba ng isang migrasyon at isang proyekto ng arkeolohiya kapag pinalitan ang kahon.