Anpassa Linux VPN-klienten till den gamla enhetens protokoll

Fyra protokollfamiljer täcker nästan varje enhet som fortfarande står i ett rack, och var och en misslyckas olika på Linux. Den andra sidans publicerade portar och konfigurerade förslag avgör ditt paket, inte den distribution du råkar köra. Att installera det ett foruminlägg nämner och sedan redigera tills något ansluter är hur en eftermiddag försvinner. Läs enheten, installera som andra, verifiera som tredje.

Notera vad den andra sidan publicerar

Skriv ned protokollet, portarna och autentiseringen som enheten förväntar sig innan du öppnar en pakethanterare. Fyra familjer täcker det mesta av gammal utrustning, och tabellen nedan är hela beslutet på en skärm.

Handboken och enhetens egna brandväggsregler är pålitligare än protokollnamnet på dess inloggningssida. En enhet som annonserar IPsec talar kanske bara IKEv1, och en firmwareversion som ingen har tillämpat är kanske det som till slut lägger till IKEv2. Bekräfta både datavägen och konfigurationsporten, för det är där gammal utrustning och moderna nätverk går isär. Att ta detta steg fel innebär att felsöka klienten mot en funktion som den andra sidan aldrig hade.

PPTP: bevisa GRE innan du redigerar pppd

PPTP på Linux är inte en daemon du startar utan ett pppd-anrop, och anslutningsparametrarna bor i en namngiven peer-fil som pppd läser när den anropas. Distributioner paketerar det fortfarande, även om protokollets kända svagheter gör det olämpligt för något känsligt, så håll det strikt för en enhet som inte erbjuder något annat. Håll koll på GRE medan klienten förhandlar, med en kort inspelning i stället för en gissning. Felet som kostar mest tid är inte autentiseringen utan den saknade datavägen.

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

Om konfigurationen slutförs och länken aldrig bär trafik, misstänk GRE-vägen innan du rör inloggningsuppgifterna. Molnets säkerhetsgrupper behöver en uttrycklig regel för protokoll 47, och vissa nät blockerar det helt utan synligt fel. Testa från nätet du faktiskt ska använda, inte från ett labb som tillåter allt.

L2TP/IPsec: ett passande förslag slår tio försök

Läs daemonens logg i stället för skrivbordsdialogen, eftersom dialogen slår ihop flera olika fel till ett enda meddelande. Ett NO_PROPOSAL_CHOSEN-fel hör till första fasen: klienten erbjöd en kryptering, en hash eller en Diffie-Hellman-grupp som servern inte accepterar. Lista vad enheten stöder och skriv ett passande förslag, eftersom slumpmässiga kombinationer oftast ger samma fel långsammare. På ett skrivbord är den praktiska klienten NetworkManager L2TP-insticksmodulen med strongSwan eller Libreswan under.

En förslagssträng som betyder en sak för en skrivbordsinsticksmodul kan betyda något annat för den daemon den överlämnar arbetet till, så håll syntaxen lämplig för lagret du redigerar. Om enheten också kräver en tunnelhemlighet är det ett eget steg från IPsec-nyckeln. Bekräfta vilken av de två gränssnittet frågar efter innan du skriver något i det.

Aggressiv IKEv1 med XAuth, och portalfallet

En ändpunkt i FortiGate-stil vill vanligtvis ha aggressivt läge med XAuth och en adress i konfigurerat läge, vilket en grafisk insticksmodul kanske inte visar alls. Den inbyggda daemonen hanterar det, och blocket nedan är formen för den konfigurationen, inte en fullständig fil. Kontrollera tillverkarens aktuella dokumentation för förslagsvärdena.

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

Äldre strongSwan-versioner använde xauth=client där version 5 använder leftauth2=xauth, så ett kopierat utdrag kan misslyckas enbart på syntaxen. För en TLS-portal hanterar openconnect, som talar AnyConnect-protokollet, Cisco och de flesta omdöpta märken, och det behöver en TUN-enhet plus behörigheterna att konfigurera den. Ange portaladressen exakt som webbläsaren visar den, inklusive varje sökväg enheten förväntar sig, och kontrollera sedan den tilldelade adressen innan du testar något bakom den. Att skapa gränssnittet i förväg tar bort en klass av överraskningar under konfigurationen.

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

Anslut och verifiera sedan i fast ordning

Kör exakt en VPN-hanterare åt gången, eftersom en NetworkManager-profil och en handstartad daemon kommer att slåss om rutter och DNS. Ta ned profilen innan du testar en manuell anslutning och bekräfta att inget gammalt tunnelgränssnitt överlever. Verifiera sedan i denna ordning: tunneladress, rutt till den enda interna värd du behöver, namnmatchning och slutligen en faktisk begäran. En grön ikon bevisar autentiseringen och ingenting annat.

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

Om ett steg misslyckas, stanna där i stället för att testa nästa, eftersom ett DNS-fel nedströms från en trasig rutt inte lär dig något. Spara en kopia av den fungerande profilen innan du experimenterar, eftersom en raderad anslutningsfil lätt försvinner och är besvärlig att bygga upp igen. Håll förslagsvärdena i samma anteckning som enhetsmodellen och firmwareversionen, eftersom den anteckningen är skillnaden mellan en migrering och ett arkeologiprojekt när lådan byts ut.