Alĝustigu la Linux VPN-klienton al la protokolo de la malnova aparato

Kvar protokolaj familioj kovras preskaŭ ĉiun aparaton ankoraŭ starantan en rako, kaj ĉiu malsukcesas malsame sur Linux. La publikigitaj havenoj kaj agorditaj proponoj de la fora fino decidas vian pakaĵon, ne la distribuo, kiun vi hazarde uzas. Instali tion, kion mencias forumafŝaŭdo, kaj poste redakti ĝis io konektiĝas, estas la maniero per kiu posttagmezo malaperas. Legu la aparaton, instalu due, kontrolu trie.

Notu, kion publikigas la fora fino

Notu la protokolon, la havenojn kaj la aŭtentikigon, kiujn la aparato atendas, antaŭ ol malfermi pakaĵadministrilon. Kvar familioj kovras la plejparton de malnova ekipaĵo, kaj la suba tabelo estas la tuta decido sur unu ekrano.

La manlibro kaj la propraj fajroŝirmilaj reguloj de la aparato estas pli fidindaj ol la protokola nomo sur ĝia ensaluta paĝo. Aparato, kiu reklamas IPsec, eble parolas nur IKEv1, kaj firmvara eldono, kiun neniu instalis, eble estas tio, kio fine aldonas IKEv2. Konfirmu kaj la datuman vojon kaj la agordan havenon, ĉar ĝuste tie malnova ekipaĵo kaj modernaj retoj malkongruas. Erari ĉe ĉi tiu paŝo signifas sencimigi vian klienton kontraŭ trajto, kiun la alia fino neniam havis.

PPTP: pruvu GRE antaŭ ol redakti pppd

PPTP sur Linux ne estas demono, kiun vi startigas, sed alvoko de pppd, kaj la konektaj parametroj loĝas en nomita peer-dosiero, kiun pppd legas kiam ĝi estas alvokata. Distribuoj ankoraŭ pakaĵas ĝin, kvankam la konataj malfortoj de la protokolo igas ĝin netaŭga por io ajn sentema, do tenu ĝin strikte por aparato, kiu ofertas nenion alian. Atentu GRE dum la kliento intertraktas, per mallonga kapto anstataŭ konjekto. La malsukceso, kiu perdigas plej multe da tempo, estas ne la aŭtentikigo sed la mankanta datuma vojo.

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

Se la agordo finiĝas kaj la ligo neniam portas trafikon, suspektu la GRE-vojon antaŭ ol tuŝi akreditaĵojn. Nubaj sekurecgrupoj bezonas eksplicitan regulon por protokolo 47, kaj iuj retoj tute blokas ĝin sen videbla eraro. Testu el la reto, kiun vi efektive uzos, ne el laboratorio, kiu permesas ĉion.

L2TP/IPsec: unu kongrua propono venkas dek provojn

Legu la demonan protokolon anstataŭ la labortablan dialogon, ĉar la dialogo kunfandas plurajn malsamajn malsukcesojn en unu mesaĝon. Eraro NO_PROPOSAL_CHOSEN apartenas al la unua fazo: la kliento proponis ĉifradon, haketon aŭ Diffie-Hellman-grupon, kiun la servilo ne akceptos. Listigu, kion subtenas la aparato, kaj skribu unu proponon kongruan kun ĝi, ĉar hazardaj kombinaĵoj plej ofte produktas la saman eraron pli malrapide. Sur labortablo la praktika kliento estas la kromaĵo NetworkManager L2TP kun strongSwan aŭ Libreswan sube.

Propona ĉeno, kiu por labortabla kromaĵo signifas unu aferon, povas signifi alian por la demono, al kiu ĝi transdonas la laboron, do tenu la sintakson taŭga por la tavolo, kiun vi redaktas. Se la aparato ankaŭ postulas tunelan sekreton, tio estas aparta stadio de la IPsec-ŝlosilo. Konfirmu, pri kiu el la du la interfaco demandas, antaŭ ol enigi ion.

Agresa IKEv1 kun XAuth, kaj la portala kazo

Finpunkto laŭ stilo FortiGate kutime volas agresan reĝimon kun XAuth kaj adreson en agordita reĝimo, kiun grafika kromaĵo eble tute ne elmontras. La denaska demono pritraktas ĝin, kaj la suba bloko estas la formo de tiu agordo, ne kompleta dosiero. Kontrolu la aktualan dokumentaron de la vendisto por la proponaj valoroj.

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

Pli malnovaj eldonoj de strongSwan uzis xauth=client tie, kie versio 5 uzas leftauth2=xauth, do kopiita fragmento povas malsukcesi sole pro sintakso. Por TLS-portalo, openconnect parolanta la protokolon AnyConnect pritraktas Cisco kaj la plej multajn renomitajn markojn, kaj ĝi bezonas TUN-aparaton plus la privilegiojn por agordi ĝin. Transdonu la portalan adreson ĝuste kiel la retumilo montras ĝin, inkluzive de iu ajn vojo, kiun la aparato atendas, poste kontrolu la asignitan adreson antaŭ ol testi ion malantaŭ ĝi. Antaŭe krei la interfacon forigas unu klason de surprizoj dum la agordo.

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

Konektiĝu, poste kontrolu laŭ fiksa ordo

Rulu ĝuste unu VPN-administrilon samtempe, ĉar NetworkManager-profilo kaj permane startigita demono kverelos pri vojoj kaj DNS. Mallevu la profilon antaŭ ol testi permanan konekton, kaj konfirmu, ke neniun malnovan tunelan interfacon postrestas. Poste kontrolu laŭ ĉi tiu ordo: tunela adreso, vojo al la ununura interna gastiganto, kiun vi bezonas, nomrezolucio, kaj fine efektiva peto. Verda piktogramo pruvas aŭtentikigon kaj nenion alian.

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

Se iu paŝo malsukcesas, haltu tie anstataŭ testi la sekvan, ĉar DNS-malsukceso malsupre de rompita vojo instruas al vi nenion. Konservu kopion de la funkcianta profilo antaŭ ol eksperimenti, ĉar forigita konekta dosiero facile perdiĝas kaj tede rekonstruiĝas. Tenu la proponajn valorojn en la sama noto kiel la aparata modelo kaj la firmvara versio, ĉar tiu noto estas la diferenco inter migrado kaj arkeologia projekto, kiam la skatolo anstataŭiĝos.