Tilpas Linux VPN-klienten til den gamle enheds protokol

Fire protokolfamilier dækker næsten enhver enhed, der stadig står i et rack, og hver af dem fejler forskelligt på Linux. Den fjerne ends offentliggjorte porte og konfigurerede forslag bestemmer din pakke, ikke den distribution, du tilfældigvis kører. At installere hvad et forumindlæg nævner og derefter redigere, indtil noget forbinder, er måden, hvorpå en eftermiddag forsvinder. Læs enheden, installer som nummer to, verificer som nummer tre.

Skriv ned, hvad den fjerne ende offentliggør

Skriv protokollen, portene og godkendelsen ned, som enheden forventer, før du åbner et pakkehåndteringsprogram. Fire familier dækker det meste gamle udstyr, og tabellen nedenfor er hele beslutningen på én skærm.

Manualen og enhedens egne firewallregler er mere troværdige end protokolnavnet på dens login-side. En enhed, der annoncerer IPsec, taler måske kun IKEv1, og en firmwareudgivelse, som ingen har anvendt, er måske det, der til sidst tilføjer IKEv2. Bekræft datastien såvel som opsætningsporten, for det er her, gammelt udstyr og moderne netværk er uenige. At tage dette trin forkert betyder at fejlfinde din klient mod en funktion, den anden ende aldrig havde.

PPTP: bevis GRE, før du redigerer pppd

PPTP på Linux er ikke en dæmon, du starter, men et pppd-kald, og forbindelsesparametrene ligger i en navngivet peer-fil, som pppd læser, når den kaldes. Distributioner pakker det stadig, selvom protokollens kendte svagheder gør det uegnet til noget følsomt, så hold det strengt til en enhed, der ikke tilbyder andet. Hold øje med GRE, mens klienten forhandler, med en kort optagelse i stedet for et gæt. Den fejl, der spilder mest tid, er ikke godkendelsen, men den manglende datasti.

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

Hvis opsætningen fuldføres, og forbindelsen aldrig bærer trafik, skal du mistænke GRE-stien, før du rører ved legitimationsoplysninger. Cloud-sikkerhedsgrupper har brug for en eksplicit regel for protokol 47, og nogle netværk blokerer den helt uden en synlig fejl. Test fra det netværk, du faktisk vil bruge, ikke fra et laboratorium, der tillader alt.

L2TP/IPsec: ét matchende forslag slår ti forsøg

Læs dæmonens log i stedet for skrivebordsdialogen, fordi dialogen samler flere forskellige fejl i én meddelelse. En NO_PROPOSAL_CHOSEN-fejl hører til fase et: klienten tilbød en kryptering, hash eller Diffie-Hellman-gruppe, som serveren ikke vil acceptere. Opregn, hvad enheden understøtter, og skriv ét forslag, der matcher det, fordi tilfældige kombinationer oftest giver den samme fejl langsommere. På et skrivebord er den praktiske klient NetworkManager L2TP-plugin med strongSwan eller Libreswan nedenunder.

En forslagsstreng, der betyder én ting for et skrivebordsplugin, kan betyde noget andet for den dæmon, den overdrager arbejdet til, så hold syntaksen passende til det lag, du redigerer. Hvis enheden også kræver en tunnelhemmelighed, er det et separat trin fra IPsec-nøglen. Bekræft, hvilken af dem grænsefladen spørger efter, før du skriver noget i den.

IKEv1 aggressiv med XAuth, og portal-tilfældet

Et endepunkt i FortiGate-stil vil normalt have aggressiv tilstand med XAuth og en adresse i konfigureret tilstand, hvilket et grafisk plugin måske slet ikke viser. Den indbyggede dæmon håndterer det, og blokken nedenfor er formen af den konfiguration snarere end en komplet fil. Se leverandørens aktuelle dokumentation for forslagsværdierne.

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

Ældre strongSwan-udgivelser brugte xauth=client, hvor version 5 bruger leftauth2=xauth, så et kopieret uddrag kan fejle alene på syntaks. Til en TLS-portal håndterer openconnect, der taler AnyConnect-protokollen, Cisco og de fleste omdøbte mærker, og det kræver en TUN-enhed plus rettighederne til at konfigurere den. Send portaladressen præcis, som browseren viser den, inklusive enhver sti, enheden forventer, og kontroller derefter den tildelte adresse, før du tester noget bag den. At oprette grænsefladen på forhånd fjerner en klasse af overraskelser under opsætningen.

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

Forbind, og verificer derefter i en fast rækkefølge

Kør præcis én VPN-håndtering ad gangen, fordi en NetworkManager-profil og en håndstartet dæmon vil slås om ruter og DNS. Tag profilen ned, før du tester en manuel forbindelse, og bekræft, at ingen gammel tunnelgrænseflade overlever. Verificer derefter i denne rækkefølge: tunneladresse, rute til den eneste interne vært, du har brug for, navneopløsning og til sidst en faktisk anmodning. Et grønt ikon beviser godkendelse og intet andet.

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

Hvis et trin fejler, skal du stoppe der i stedet for at teste det næste, fordi en DNS-fejl nedstrøms for en brudt rute ikke lærer dig noget. Gem en kopi af den fungerende profil, før du eksperimenterer, fordi en slettet forbindelsesfil er let at miste og besværlig at genskabe. Opbevar forslagsværdierne i samme note som enhedens model og firmwareversion, fordi den note er forskellen mellem en migrering og et arkæologiprojekt, når boksen udskiftes.