Teine WAN VPN-kirje ei tööta, samal ajal kui esmane töötab edasi

Esmane tunnel püsib püsti, kasutajad töötavad edasi ja teine ISP-liin seisab jõude, ükskõik mida muudate. Avaldasite varuliini jaoks aadressi, suunasite sellele nime, lisasite võib-olla kliendile varukirje, ja klient kas ei proovi seda kunagi või autendib end ja sureb seejärel. Minu jälgitud juhtudel oli ümberlülitusfunktsioon tavaliselt korras; puudu oli üks viiest asjast, mis teevad kirje kasutatavaks. Nimi võib laheneda varuaadressiks, samal ajal kui sellel liidesel ei kuula miski, ja kuulaja võib ühenduse vastu võtta, samal ajal kui vastus väljub esmase liidese kaudu. Käsitlege iga WAN-i eraldi kirjena, millel on oma leping, ja rike lakkab nägemast kliendi veana.

Iga WAN vajab oma kirjelepingut

Märkige iga WAN-i kohta viis välja: avalik nimi ja aadress, transport ja port, seda lõpetav liides või kontekst, partneri identiteet, mida see peab esitama, ja kust vastus väljub. Kaks liini tähendavad kahte täielikku komplekti. Kui teisel komplektil pole lõpetavat liidest ega tagasiteed, pole teil varukirjet; teil on DNS-kirje, mis kirjeldab kavatsust.

Seade ja selle versioon peavad samuti seda lahendust toetama. DNS-kirje ei saa avada teenust teisel liidesel ja paljudel platvormidel seadistatakse kuulaja aadressi, mitte seadme järgi. ASA-l seob liidesepõhine IPsec krüptokaardid ja tunneligrupid välisliidesega, seega teine üleslink vajab poliitikat seal, kuhu need paketid tegelikult saabuvad. Marsruudipõhised lahendused käituvad teisiti: kuulaja võib siduda iga aadressiga või ühe nimetatud aadressiga, ja see valik otsustab, kas ISP B saab üldse vastata.

Kontrollige, kas teine WAN tõesti vastab

Testige mõlema liini välisküljelt, mitte lüüsi taga olevalt masinalt, ja testige täpselt seda nime, mida kliendiprofiil kasutab. TLS-kuulaja puhul on kiire kontroll openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts käivitatud väljaspool teie võrku olevalt hostilt. Soovite lõpetatud kätlust, mille ahel vastab profiilis olevale nimele, mitte lihtsalt TCP-porti, mis ühenduse vastu võtab.

RFC 9525 selgitab, mida klient kontrollib: identiteeti, kuhu ta kavatses jõuda, võrrelduna sertifikaadiga, mida teenus esitab. Teine kirje, mis annab tagasi esmase kirje sertifikaadi, või vaikesertifikaat, kus pole kumbagi nime loetletud, ebaõnnestub selles testis, kuigi port on avatud ja tulemüür lubab seda.

Siinset enamikku riketest selgitavad kaks mustrit. Ripakil ühendus tähendab tavaliselt, et sellel liidesel pole kuulajat, juurdepääsureeglit, mis lubab ainult esmaseid alamvõrke, või teise liini ees olevat operaatori seadet, mis pordi maha viskab. Vale identiteediga lõppev kätlus tähendab tavaliselt teist trustpoint'i, vaikimisi virtuaalset hosti või esmasest kopeeritud konfiguratsiooni, kus identiteeti pole kohandatud.

Jälgige vastust, mitte ainult päringut

Teine WAN katkeb tavaliselt tagasiteel. Päring saabub ISP B kaudu, seade vastab ja vastus väljub ISP A vaikimisi marsruudi kaudu sellise lähteaadressiga, mida klient kunagi ei küsinud. Olekuga tõlge teeb asja hullemaks: kui vastendus ehitati esmase liidese jaoks, jätab tagasitulev pakett tõlke vahele või kannab allikat, mille kliendi tulemüür kõrvale heidab. Teenusepakkujad heidavad kõrvale ka lähteaadressid, mis ei kuulu liini, mille nad teile andsid, ja seetõttu näeb see välja nagu ühesuunaline must auk, mitte puhas protokolliviga.

Kontrollige marsruudiotsust liiklusele, mille allikas on teine kirje. Vastus peaks väljuma liidesest, kuhu päring saabus, või kandma vähemalt aadressi, mida kaugem pool aktsepteerib selle tee osana. Poliitikapõhise marsruutimise platvormidel tähendab see reeglit, mis on seotud sissetuleva liidese või tõlgitud allikaga, pluss tõlkeavaldist, mis on seotud iga välisliidesega. Jäädvustage samaaegselt mõlemal liidesel, kui klient ühendub; ISP B-le saabuv SYN ja ISP A-lt väljuv SYN-ACK lahendavad küsimuse ühe jooksuga.

Andke kliendile võimalus teisest kirjest teada saada

Ümberlülitus on kliendipoolne otsus ja iga kliendiperekond õpib alternatiive erinevalt. ASA-l edastatakse varuserverite nimekiri grupipoliitika webvpn-atribuutide kaudu, samal ajal kui teised kliendid ootavad nimekirja profiili sees või käsitsi teist profiili, mille kasutaja valib. Cisco ühenduspoliitika juhend kirjeldab nii kliendis seadistatud kui ka lüüsi poolt pakutavat varuteavet ja neid protokollipõhiseid üksikasju ei tohiks üldistada igale kliendile ega tunnelirežiimile. Kinnitage, millist mehhanismi juurutatud klient rakendab, enne kui ehitate teise kirje vale mehhanismi ümber.

Olenemata mehhanismist peab klient suutma alternatiivse nime lahendada enne, kui kaotab esmase tee. Just seda sõltuvust inimesed tähele ei pane: kui varunimele vastab resolver, mis on kättesaadav ainult just katkenud tunneli kaudu, ei saa varulahendus üldse alata. Avaldage teine nimi resolveris, mis vastab kohapeal või interneti kaudu. Oodake pärast üleminekut uut autentimist ja uut rakendusesessiooni, sest kliendi ümberlülitus ei ole olekuga ümberlülitus ja pikaajalised sessioonid ei jää selle üle elama.

Üks aadress kahe teenusepakkuja juures on teine toode

Ühe avaliku aadressi kättesaadavana hoidmine mõlema liini kaudu on marsruutimisteenus, mitte VPN-i märkeruut. See vajab aadressiruumi, mida mõlemad pakkujad on valmis kandma, selliselt teatatud, et nende võrgud seda aktsepteerivad, ja seda annab mitmikühendus pakkujast sõltumatu ruumi ja BGP-ga. ISP A aadressi omistamine ISP B liidesele ei vii sinna; pakett saabub võrku, mis ei teatanud eesliidet kunagi, ja visatakse ülalpool ära.

Kahe kirje avaldamiseks ei vaja te neist midagi. Kui klient suudab hoida kahte nime ja nende vahel ümber lülituda, piisab kahest sõltumatust kirjest ja te väldite AS-numbrit, peering-kokkulepet ja eesliidet, mida peab kõikjal aktsepteerima. Kaaluge kaasaskantava aadressi valikut ainult siis, kui vajate tõesti ühte stabiilset sisenemispunkti, mida kliente ei saa ümber seadistada seda asendama, või kui DNS-põhine ümberlülitus oma TTL-viivitusega on katkestuse jaoks liiga aeglane, mille vastu te projekteerite.

Mida järgmisena kontrollida

Liikuge ebaõnnestunud kirjest väljapoole selles järjekorras: kas teine aadress vastab väljast, kas see esitab identiteedi, mida klient ootab, kas vastus väljub seda teed, mida mööda päring saabus, ja kas klient saab nime teada enne, kui seda vajab. Kui vastus on ei, parandage see kiht ja testige uuesti juurutatud profiiliga, mitte testhostiga, sest labori kätlus tõestab vähem kui tegeliku kliendi lõpetatud ühendus.

Pidage iga WAN-i kohta lühikest kirjet aadressi, pordi, lõpetava liidese, sertifikaadi nime, tagasitee ja tõlkereegliga ning kontrollige seda uuesti alati, kui liin, NAT-seade või kliendi versioon muutub. Tühikäigul varuteed mädanevad vaikselt: miski ei hoita kirje eest, mida keegi ei kasuta, kuni päevani, mil kõik sõltuvad sellest.