vpnc-gruppehemmelighed eller dit login: hvilket felt tager hvad?
En vpnc-profil beder om et gruppe-ID, en gruppehemmelighed og et XAuth-login, og folk putter kontoens adgangskode i det forkerte felt. Kortlæg hvert felt efter dets rolle.
Første gang nogen giver dig en vpnc-profil, spørger dialogboksen om fire ting og ser ud som om den vil have én adgangskode. Det vil den ikke: en forudelt gruppehemmelighed og et individuelt XAuth-login er separate værdier med separate ejere, og at sætte kontoens adgangskode i gruppefeltet giver en fejl, der ligner en dårlig adgangskode snarere end et forkert felt. At få kortlægningen rigtig er hele opgaven her. Protokollen nedenunder er en andens migrationsprojekt, og derfor er intet af dette et argument for at bygge nye IKEv1-tunneler.
To hemmeligheder, to ejere, én dialog
En gruppehemmelighed tilhører gatewayprofilen. Alle, der forbinder gennem den profil, bruger den samme værdi, og netop derfor kan den ikke identificere en person og kan ikke trækkes tilbage fra én bærbar uden at ændre den for alle andre brugere af profilen. XAuth-brugernavnet og -adgangskoden tilhører derimod mennesket, og gatewayen vurderer dem i en anden fase, efter at IPsec-forbindelsen allerede er oppe.
Det er denne tofasede form, folk overser. Tunneloprettelse og brugerautentificering er forskellige udvekslinger med forskellige input, så en klient, der aldrig når frem til anmodningen om loginoplysninger, er slet ikke fejlet på login. Læs dialogen som to kolonner i stedet for én: værdier for hele profilen til venstre, personlige værdier til højre. Når en forbindelse fejler, er den kolonne, du udfyldte sidst, ikke automatisk den skyldige.
Kortlæg felterne efter rolle, ikke efter etiket
vpnc navngiver sine direktiver i projektdokumentationen, og hver grafisk frontend omdøber dem. Oversæt rollen for hver værdi, så holder etiketterne op med at betyde noget:
| Directive | What it carries | Who owns it |
|---|---|---|
| IPSec gateway | Address or hostname of the remote VPN endpoint | Operator |
| IPSec ID | Group identifier selecting the profile on that gateway | Operator |
| IPSec secret | Group preshared secret, not an account password | Profile, shared |
| Xauth username and password | Credentials for the per-user stage after the tunnel | Person |
En frontend, der viser »Brugernavn« og »Adgangskode« ved siden af et gruppefelt, er ikke forkert — det er de samme tre værdier under forskellige navne. Det, der går galt, er at udfylde et felt, fordi en værdi passer i det. En gruppehemmelighed indsat som brugeradgangskode autentificerer profilen og fejler derefter i brugerfasen; en kontoadgangskode indsat som gruppehemmelighed fejler tidligere, før nogen anmodning, og sender folk til at lede efter problemet i firewalls, mens det bor i et tekstfelt.
Hvad et gruppeidentifikator ikke er
Ordet gruppe indbyder til en forkert læsning. Et gruppeidentifikator her er en vælger, der fortæller gatewayen, hvilken profilkonfiguration der skal anvendes; den siger intet om medlemskab af en mappe, og et matchende navn på begge sider er et tilfælde, indtil operatøren bekræfter det. Autorisation sker, efter XAuth lykkes, afgjort af hvad end gatewayen er konfigureret til at konsultere, og intet af det er synligt i klientens dialog.
Samme forsigtighed gælder for gruppehemmeligheden. At kende den er ikke en identitet, og at cirkulere én hemmelighed rundt i et team er en driftsbeslutning med konsekvenser, som klienten ikke kan vise dig.
Afklar den tvetydige instruks, før du forbinder
Ved overleveringsnotater fra gamle systemer står der ofte en linje som »brug den dedikerede offentlige IP«. Den formulering kan betyde den adresse, som en allowliste på den anden side forventer, at din trafik ankommer fra — det er en udgangsegenskab ved operatørens netværk og har intet at gøre med det endepunkt, du skriver i gatewayfeltet. Spørg, hvilken af de to der menes, før værdien går nogen steder hen. Udfyldt omvendt sender den hver pakke til en adresse, der aldrig svarer, og den resulterende timeout ligner en blokeret port.
Bed om fire ting gennem organisationens verifikationskanal: hvilken klient og protokol der understøttes, hvilket endepunkt der skal bruges, hvilken identitet gatewayen vil fremvise, og hvordan loginoplysninger overdrages. Hold rigtige hemmeligheder ude af skærmbilleder, sager og delte fejlfindingsnotater. Deaktiver ikke certifikatkontroller, og indsæt ikke en gammel cipher-liste for at få en anderledes konfigureret tjeneste til at se kompatibel ud, for en forbindelse, der kun virker ved at svække verifikationen, er ikke den forbindelse, du blev bedt om at bygge.
Hold den gamle profil ærlig
IKEv1 er forældet, og RFC 9395 er dokumentet, der citeres, når migrationsspørgsmålet dukker op. En vellykket feltkortlægning er ikke bevis for, at protokollen hører hjemme i et nyt design; det, den køber, er en fungerende forbindelse, mens udskiftningen planlægges, plus et skriftligt omfang og en ejer af den migration.
Verificér derefter mod kravet i stedet for mod dialogen. Efter forbindelsen skal du bekræfte, at tunnelinterfacet har den forventede adresse, og at en intern destination rutes gennem det; hvis det oprindelige krav nævnte en udgangsadresse til en allowliste, skal du også bekræfte den adresse, for det er et andet faktum end at tunnelen er oppe. En profil, der autentificerer korrekt og ikke ruter noget, har stadig fejlet den opgave, den blev oprettet til.