Pas die Linux-VPN-kliënt by die ou toestel se protokol

Vier protokolfamilies dek byna elke toestel wat nog in 'n rek staan, en elkeen misluk anders op Linux. Die gepubliseerde poorte en gekonfigureerde voorstelle van die ver kant bepaal jou pakket, nie die distribusie wat jy toevallig gebruik nie. Om te installeer wat 'n forumplasing noem en dan te redigeer tot iets konnekteer, is hoe 'n middag verdwyn. Lees die toestel, installeer tweede, verifieer derde.

Teken aan wat die ver kant publiseer

Skryf die protokol, die poorte en die verifikasie neer wat die toestel verwag voordat jy 'n pakketbestuurder oopmaak. Vier families dek die meeste ou toerusting, en die tabel hieronder is die hele besluit op een skerm.

Die handleiding en die toestel se eie firewallreëls is meer betroubaar as die protokolnaam op sy aanmeldbladsy. 'n Toestel wat IPsec adverteer, mag net IKEv1 praat, en 'n firmware-weergawe wat niemand toegepas het nie, is dalk wat uiteindelik IKEv2 byvoeg. Bevestig die datapad sowel as die opstelpoort, want dit is waar ou toerusting en moderne netwerke van mekaar verskil. Om hierdie stap verkeerd te kry, beteken om jou kliënt te ontfout teen 'n kenmerk wat die ander kant nooit gehad het nie.

PPTP: bewys GRE voordat jy pppd wysig

PPTP op Linux is nie 'n daemon wat jy begin nie, maar 'n pppd-oproep, en die verbindingsparameters woon in 'n genoemde peer-lêer wat pppd lees wanneer dit geroep word. Distribusies verpak dit steeds, hoewel die protokol se bekende swakhede dit ongeskik maak vir enigiets sensitiefs, so hou dit streng vir 'n toestel wat niks anders bied nie. Let op GRE terwyl die kliënt onderhandel, met 'n kort opname eerder as 'n raaiskoot. Die mislukking wat die meeste tyd mors, is nie verifikasie nie, maar die ontbrekende datapad.

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

As die opstel voltooi en die skakel nooit verkeer dra nie, vermoed die GRE-pad voordat jy aanmeldgegewens aanraak. Wolk-sekuriteitsgroepe het 'n eksplisiete reël vir protokol 47 nodig, en sommige netwerke blokkeer dit heeltemal sonder 'n sigbare fout. Toets vanuit die netwerk wat jy werklik gaan gebruik, nie vanuit 'n laboratorium wat alles toelaat nie.

L2TP/IPsec: een passende voorstel klop tien pogings

Lees die daemon-log eerder as die lessenaar-dialoog, want die dialoog val verskeie verskillende mislukkings in een boodskap saam. 'n NO_PROPOSAL_CHOSEN-fout hoort by fase een: die kliënt het 'n enkripsie, hash of Diffie-Hellman-groep aangebied wat die bediener nie sal aanvaar nie. Lys wat die toestel ondersteun en skryf een voorstel wat daarby pas, want lukraak kombinasies lewer meestal dieselfde fout stadiger op. Op 'n lessenaar is die praktiese kliënt die NetworkManager L2TP-inprop met strongSwan of Libreswan daaronder.

'n Voorstelstring wat vir 'n lessenaar-inprop een ding beteken, kan iets anders beteken vir die daemon waaraan dit die werk oorhandig, so hou die sintaks gepas vir die laag wat jy wysig. As die toestel ook 'n tonnelgeheim eis, is dit 'n aparte stadium van die IPsec-sleutel. Bevestig vir watter een die koppelvlak vra voordat jy enigiets daarin tik.

IKEv1 aggressief met XAuth, en die portaalgeval

'n FortiGate-tipe eindpunt wil gewoonlik aggressiewe modus met XAuth en 'n gekonfigureerde-modus-adres, wat 'n grafiese inprop dalk glad nie blootlê nie. Die inheemse daemon hanteer dit, en die blok hieronder is die vorm van daardie konfigurasie eerder as 'n volledige lêer. Kyk na die verskaffer se huidige dokumentasie vir die voorstelwaardes.

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

Ouer strongSwan-weergawes het xauth=client gebruik waar weergawe 5 leftauth2=xauth gebruik, so 'n gekopieerde brokkie kan op sintaks alleen misluk. Vir 'n TLS-portaal hanteer openconnect, wat die AnyConnect-protokol praat, Cisco en die meeste herhandelsmerke, en dit het 'n TUN-toestel plus die regte om dit op te stel nodig. Gee die portaaladres presies soos die blaaier dit wys, insluitend enige pad wat die toestel verwag, en kyk dan na die toegewysde adres voordat jy enigiets daaragter toets. Om die koppelvlak vooraf te skep, verwyder een klas verrassing tydens die opstel.

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

Verbind, verifieer dan in 'n vaste volgorde

Hardloop presies een VPN-bestuurder op 'n slag, want 'n NetworkManager-profiel en 'n met die hand beginte daemon sal oor roetes en DNS baklei. Bring die profiel af voordat jy 'n handmatige verbinding toets, en bevestig dat geen verouderde tonnelkoppelvlak oorleef nie. Verifieer dan in hierdie volgorde: tonneladres, roete na die enkele interne gasheer wat jy nodig het, naamoplossing, en uiteindelik 'n werklike versoek. 'n Groen ikoon bewys verifikasie en niks anders nie.

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

As 'n stap misluk, stop daar eerder as om die volgende een te toets, want 'n DNS-mislukking stroomaf van 'n gebreekte roete leer jou niks. Stoor 'n kopie van die werkende profiel voordat jy eksperimenteer, want 'n verwyderde verbindingslêer is maklik om te verloor en vervelig om te herkonstrueer. Hou die voorstelwaardes in dieselfde nota as die toestelmodel en firmware-weergawe, want daardie nota is die verskil tussen 'n migrasie en 'n argeologieprojek wanneer die boks vervang word.