A Linux VPN-ügyfél illesztése a régi eszköz protokolljához

Négy protokollcsalád fedi gyakorlatilag minden eszközt, amely még a rackben áll, és mindegyik másképp hibázik Linuxon. A távoli fél közzétett portjai és beállított javaslatai döntik el a csomagot, nem az a disztribúció, amelyet épp futtat. Telepíteni, amit egy fórumbejegyzés említ, majd addig szerkeszteni, amíg valami csatlakozik — így tűnik el egy délután. Olvassa el az eszközt, másodikként telepítsen, harmadikként ellenőrizzen.

Rögzítse, mit tesz közzé a távoli fél

Írja fel a protokollt, a portokat és a hitelesítést, amelyet az eszköz elvár, mielőtt megnyit egy csomagkezelőt. Négy család fedi a régi berendezések nagy részét, és az alábbi táblázat az egész döntés egyetlen képernyőn.

A kézikönyv és az eszköz saját tűzfal-szabályai megbízhatóbbak, mint a protokoll neve a bejelentkező oldalán. Egy IPsecet hirdető eszköz talán csak IKEv1-et beszél, és egy firmware-kiadás, amelyet senki nem alkalmazott, talán az, ami végül hozzáadja az IKEv2-t. Erősítse meg az adatútvonalat és a beállítási portot is, mert itt tér el a régi berendezés a modern hálózatoktól. Ha ezt a lépést elrontja, az ügyfelet olyan funkció ellen hibakeresi, amely a másik oldalon soha nem volt.

PPTP: bizonyítsa a GRE-t, mielőtt a pppd-t szerkeszti

A PPTP Linuxon nem egy daemon, amelyet elindít, hanem pppd-hívás, és a kapcsolat paraméterei egy nevesített peer-fájlban élnek, amelyet a pppd a híváskor olvas. A disztribúciók még mindig csomagolják, bár a protokoll ismert gyengeségei alkalmatlanná teszik bármi érzékenyre, ezért szigorúan csak olyan eszköznek tartsa meg, amely semmi mást nem kínál. Figyelje a GRE-t, miközben az ügyfél tárgyal, rövid rögzítéssel, nem találgatással. A legtöbb időt pocsékoló hiba nem a hitelesítés, hanem a hiányzó adatútvonal.

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

Ha a beállítás befejeződik, és a kapcsolat soha nem visz forgalmat, gyanítsa a GRE-útvonalat, mielőtt a hitelesítő adatokhoz nyúl. A felhő biztonsági csoportoknak kifejezett szabály kell a 47-es protokollhoz, és egyes hálózatok látható hiba nélkül teljesen blokkolják. Abból a hálózatból teszteljen, amelyet valóban használni fog, ne egy laborból, amely mindent engedélyez.

L2TP/IPsec: egy illő javaslat legyőz tíz kísérletet

A daemon naplóját olvassa az asztali párbeszédablak helyett, mert az ablak több különböző hibát von össze egyetlen üzenetbe. A NO_PROPOSAL_CHOSEN hiba az első fázishoz tartozik: az ügyfél olyan titkosítást, hasht vagy Diffie-Hellman-csoportot ajánlott, amelyet a kiszolgáló nem fogad el. Sorolja fel, mit támogat az eszköz, és írjon egy illeszkedő javaslatot, mert a véletlenszerű kombinációk többnyire ugyanazt a hibát adják lassabban. Asztali gépen a gyakorlati ügyfél a NetworkManager L2TP bővítmény strongSwannal vagy Libreswannal alatta.

Egy javaslati karakterlánc, amely egy asztali bővítménynek egy dolgot jelent, mást jelenthet annak a daemonnak, amelynek a munkát átadja, ezért tartsa a szintaxist a szerkesztett réteghez illően. Ha az eszköz alagút-titkot is kér, az külön szakasz az IPsec-kulcstól. Erősítse meg, melyiket kéri a felület, mielőtt bármit beír.

Agresszív IKEv1 XAuthszal, és a portál esete

Egy FortiGate-stílusú végpont általában agresszív módot kér XAuthszal és konfigurált módú címet, amelyet egy grafikus bővítmény talán egyáltalán nem tesz elérhetővé. A natív daemon kezeli, és az alábbi blokk ennek a konfigurációnak a formája, nem teljes fájl. Nézze meg a gyártó aktuális dokumentációját a javaslati értékekhez.

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

A régebbi strongSwan-kiadások xauth=client-t használtak ott, ahol az 5-ös verzió leftauth2=xauth-t használ, így egy másolt részlet pusztán szintaxis miatt elbukhat. TLS-portálhoz a openconnect, amely az AnyConnect protokollt beszéli, kezeli a Ciscót és a legtöbb átnevezett márkát, és TUN-eszközre plusz a beállításához szükséges jogosultságokra van szüksége. A portál címét pontosan úgy adja át, ahogy a böngésző mutatja, beleértve minden útvonalat, amelyet az eszköz elvár, majd ellenőrizze a kiosztott címet, mielőtt bármit tesztel mögötte. A felület előzetes létrehozása egy osztálynyi meglepetést vesz el a beállítás során.

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

Csatlakozzon, majd rögzített sorrendben ellenőrizzen

Egyszerre pontosan egy VPN-kezelőt futtasson, mert egy NetworkManager-profil és egy kézzel indított daemon versengeni fog az útvonalakért és a DNS-ért. Vegye le a profilt, mielőtt kézi kapcsolatot tesztel, és erősítse meg, hogy nem maradt régi alagútfelület. Ezután ebben a sorrendben ellenőrizze: alagútcím, útvonal az egyetlen belső hoszthoz, amelyre szüksége van, névfeloldás, és végül egy tényleges kérés. A zöld ikon a hitelesítést bizonyítja, és semmi mást.

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

Ha egy lépés elbukik, álljon meg ott ahelyett, hogy a következőt tesztelné, mert egy törött útvonal alatti DNS-hiba semmire nem tanítja. Mentse el a működő profil másolatát, mielőtt kísérletezik, mert egy törölt kapcsolatfájl könnyen elveszik és fáradságos újraépíteni. Tartsa a javaslati értékeket ugyanabban a jegyzetben, mint az eszköz modelljét és a firmware verzióját, mert ez a jegyzet a különbség a migráció és egy régészeti projekt között, amikor a dobozt kicserélik.