Potriviți clientul VPN din Linux cu protocolul aparatului vechi

Patru familii de protocoale acoperă aproape fiecare aparat care încă stă într-un rack, și fiecare eșuează diferit pe Linux. Porturile publicate și propunerile configurate ale capătului îndepărtat decid pachetul, nu distribuția pe care o rulați din întâmplare. Să instalați ce menționează o postare pe forum și apoi să editați până se conectează ceva este felul în care dispare o după-amiază. Citiți aparatul, instalați al doilea, verificați al treilea.

Notați ce publică capătul îndepărtat

Notați protocolul, porturile și autentificarea pe care le așteaptă aparatul înainte de a deschide un manager de pachete. Patru familii acoperă cea mai mare parte a echipamentului vechi, iar tabelul de mai jos este întreaga decizie pe un singur ecran.

Manualul și regulile de firewall ale aparatului însuși sunt mai de încredere decât numele protocolului de pe pagina sa de conectare. Un aparat care anunță IPsec poate vorbi doar IKEv1, iar o versiune de firmware pe care nimeni nu a aplicat-o poate fi cea care adaugă în final IKEv2. Confirmați atât calea de date, cât și portul de configurare, pentru că acolo se despart echipamentul vechi și rețelele moderne. O greșeală la acest pas înseamnă să depanați clientul împotriva unei funcții pe care celălalt capăt nu a avut-o niciodată.

PPTP: dovediți GRE înainte de a edita pppd

PPTP pe Linux nu este un demon pe care îl porniți, ci un apel pppd, iar parametrii conexiunii stau într-un fișier peer numit pe care pppd îl citește când este apelat. Distribuțiile îl mai împachetează, deși slăbiciunile cunoscute ale protocolului îl fac nepotrivit pentru orice lucru sensibil, așa că păstrați-l strict pentru un aparat care nu oferă nimic altceva. Urmăriți GRE în timp ce clientul negociază, cu o captură scurtă în locul unei presupuneri. Eșecul care consumă cel mai mult timp nu este autentificarea, ci calea de date lipsă.

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

Dacă configurarea se încheie și legătura nu transportă niciodată trafic, suspectați calea GRE înainte de a atinge acreditările. Grupurile de securitate din cloud au nevoie de o regulă explicită pentru protocolul 47, iar unele rețele îl blochează complet fără o eroare vizibilă. Testați din rețeaua pe care o veți folosi efectiv, nu dintr-un laborator care permite totul.

L2TP/IPsec: o propunere potrivită bate zece încercări

Citiți jurnalul demonului în locul dialogului de pe desktop, pentru că dialogul contopește mai multe eșecuri distincte într-un singur mesaj. O eroare NO_PROPOSAL_CHOSEN aparține primei faze: clientul a oferit o criptare, un hash sau un grup Diffie-Hellman pe care serverul nu îl va accepta. Enumerați ce acceptă aparatul și scrieți o singură propunere care se potrivește, pentru că combinațiile aleatorii produc de obicei aceeași eroare mai încet. Pe un desktop, clientul practic este modulul L2TP al NetworkManager cu strongSwan sau Libreswan dedesubt.

Un șir de propunere care pentru un modul de desktop înseamnă un lucru poate însemna altceva pentru demonul căruia îi predă munca, așa că păstrați sintaxa potrivită stratului pe care îl editați. Dacă aparatul cere și un secret de tunel, acesta este o etapă separată de cheia IPsec. Confirmați pe care dintre cele două îl întreabă interfața înainte de a tasta ceva în ea.

IKEv1 agresiv cu XAuth, și cazul portalului

Un capăt în stil FortiGate vrea de obicei mod agresiv cu XAuth și o adresă în mod configurat, ceea ce un modul grafic poate să nu expună deloc. Demonul nativ se ocupă de asta, iar blocul de mai jos este forma acelei configurații, nu un fișier complet. Consultați documentația actuală a furnizorului pentru valorile propunerii.

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

Versiunile mai vechi de strongSwan foloseau xauth=client unde versiunea 5 folosește leftauth2=xauth, așa că un fragment copiat poate eșua doar din cauza sintaxei. Pentru un portal TLS, openconnect, care vorbește protocolul AnyConnect, se ocupă de Cisco și de majoritatea mărcilor redenumite, și are nevoie de un dispozitiv TUN plus privilegiile de a-l configura. Treceți adresa portalului exact așa cum o afișează browserul, inclusiv orice cale pe care aparatul o așteaptă, apoi verificați adresa atribuită înainte de a testa ceva în spatele ei. Crearea interfeței dinainte elimină o clasă de surprize în timpul configurării.

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

Conectați-vă, apoi verificați într-o ordine fixă

Rulați exact un manager VPN o dată, pentru că un profil NetworkManager și un demon pornit manual se vor certa pe rute și DNS. Opriți profilul înainte de a testa o conexiune manuală și confirmați că nu a supraviețuit nicio interfață de tunel veche. Apoi verificați în această ordine: adresa tunelului, ruta către singurul host intern de care aveți nevoie, rezolvarea numelor și, în final, o cerere reală. O pictogramă verde dovedește autentificarea și nimic altceva.

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

Dacă un pas eșuează, opriți-vă acolo în loc să îl testați pe următorul, pentru că un eșec DNS în aval de o rută ruptă nu vă învață nimic. Salvați o copie a profilului care funcționează înainte de a experimenta, pentru că un fișier de conexiune șters se pierde ușor și se reconstruiește anevoios. Păstrați valorile propunerii în aceeași notă cu modelul aparatului și versiunea de firmware, pentru că acea notă este diferența dintre o migrare și un proiect de arheologie când cutia este înlocuită.