Druhý vstup VPN WAN zlyháva, kým primárny stále funguje
Druhý vstup VPN WAN potrebuje vlastného poslucháča, zodpovedajúcu identitu certifikátu a spiatočnú cestu, aby ho klient mohol použiť pri prepnutí.
Primárny tunel zostáva zapnutý, používatelia pracujú ďalej a druhý okruh ISP stojí nečinne bez ohľadu na to, čo zmeníte. Zverejnili ste adresu pre záložný okruh, nasmerovali na ňu názov, možno pridali záložný vstup do klienta, a klient ho buď nikdy nevyskúša, alebo sa autentifikuje a potom spadne. V prípadoch, ktoré som sledoval, bola funkcia prepnutia zvyčajne v poriadku; chýbala jedna z piatich vecí, ktoré robia vstup použiteľným. Názov sa môže prekladať na záložnú adresu, hoci na tomto rozhraní nič nepočúva, a poslucháč môže prijať spojenie, hoci odpoveď odchádza cez primárny. Berte každú WAN ako samostatný vstup s vlastnou zmluvou a porucha prestane vyzerať ako chyba klienta.
Každá WAN potrebuje vlastnú zmluvu vstupu
Zapíšte päť polí pre každú WAN: verejný názov a adresu, transport a port, rozhranie alebo kontext, ktorý ju ukončuje, identitu partnera, ktorú má predkladať, a miesto, odkiaľ odpoveď odchádza. Dva okruhy znamenajú dve kompletné sady. Ak druhá sada nemá ukončujúce rozhranie alebo nemá spiatočnú cestu, nemáte záložný vstup; máte záznam DNS opisujúci zámer.
Zariadenie a jeho verzia tiež musia takúto zostavu podporovať. Záznam DNS neotvorí službu na inom rozhraní a na mnohých platformách sa poslucháč konfiguruje na adresu, nie na zariadenie. IPsec založený na rozhraní v ASA viaže kryptografické mapy a skupiny tunelov na vonkajšie rozhranie, takže druhý uplink potrebuje politiku tam, kam tie pakety skutočne prichádzajú. Návrhy založené na trasách sa správajú inak: poslucháč sa môže pripútať ku každej adrese alebo k jednej pomenovanej adrese, a táto voľba rozhoduje, či ISP B vôbec dokáže odpovedať.
Overte, či druhá WAN skutočne odpovedá
Testujte zvonku oboch okruhov, nie z počítača za bránou, a testujte presne ten názov, ktorý používa profil klienta. Pre poslucháča TLS je rýchlou kontrolou openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts spustené z hostiteľa mimo vašej siete. Chcete dokončené nadviazanie spojenia, ktorého reťazec zodpovedá názvu v profile, nie len port TCP, ktorý prijme spojenie.
RFC 9525 vysvetľuje, čo klient overuje: identitu, ku ktorej sa chcel dostať, porovnanú s certifikátom, ktorý služba predkladá. Druhý vstup, ktorý vracia certifikát primárneho vstupu, alebo predvolený certifikát, ktorý neuvádza ani jeden z názvov, neprejde týmto testom, aj keď je port otvorený a firewall ho povoľuje.
Dva vzory vysvetľujú väčšinu porúch tu. Spojenie, ktoré visí, zvyčajne znamená, že na tomto rozhraní nie je poslucháč, pravidlo prístupu povoľuje len primárne podsiete, alebo zariadenie operátora pred druhým okruhom zahadzuje port. Nadviazanie spojenia, ktoré sa skončí nesprávnou identitou, zvyčajne znamená iný trustpoint, predvolený virtuálny hostiteľ alebo konfiguráciu skopírovanú z primárneho bez úpravy identity.
Sledujte odpoveď, nielen požiadavku
Druhá WAN sa zvyčajne zlomí na spiatočnej ceste. Požiadavka prichádza cez ISP B, zariadenie odpovedá a odpoveď odchádza predvolenou trasou cez ISP A so zdrojovou adresou, o ktorú klient nikdy nežiadal. Preklad so stavom to zhoršuje: ak bolo mapovanie zostavené pre primárne rozhranie, spiatočný paket minie preklad alebo nesie zdroj, ktorý firewall klienta zahodí. Poskytovatelia tiež zahadzujú zdrojové adresy, ktoré nepatria okruhu, ktorý vám dali, a preto to vyzerá ako jednosmerná čierna diera namiesto čistej chyby protokolu.
Skontrolujte rozhodnutie o smerovaní pre prevádzku so zdrojom v druhom vstupe. Odpoveď by mala odísť rozhraním, cez ktoré požiadavka prišla, alebo aspoň niesť adresu, ktorú vzdialená strana akceptuje ako patriacu tejto ceste. Na platformách s politickým smerovaním to znamená pravidlo naviazané na vstupné rozhranie alebo prekladaný zdroj plus prekladový príkaz priradený ku každému vonkajšiemu rozhraniu. Zachytávajte súčasne na oboch rozhraniach, kým sa klient pripája; SYN prichádzajúci cez ISP B a SYN-ACK odchádzajúci cez ISP A vyrieši otázku v jednom behu.
Dajte klientovi spôsob, ako sa dozvedieť o druhom vstupe
Prepnutie je rozhodnutie na strane klienta a každá rodina klientov sa o alternatívach dozvedá inak. V ASA sa zoznam záložných serverov doručuje cez atribúty webvpn skupinovej politiky, kým iní klienti očakávajú zoznam v profile alebo ručný druhý profil, ktorý používateľ vyberie. Príručka Cisco k politikám pripojenia opisuje záložné informácie konfigurované v klientovi aj poskytované bránou a tieto detaily špecifické pre protokol by sa nemali zovšeobecňovať na každého klienta či režim tunela. Predtým, než postavíte druhý vstup okolo nesprávneho, potvrďte, ktorý mechanizmus nasadený klient implementuje.
Bez ohľadu na mechanizmus musí klient dokázať vyriešiť alternatívny názov skôr, než stratí primárnu cestu. Na túto závislosť ľudia zabúdajú: ak záložný názov odpovedá prekladač dostupný len cez tunel, ktorý práve zlyhal, prepnutie ani nemôže začať. Zverejnite druhý názov v prekladači, ktorý odpovedá lokálne alebo cez internet. Očakávajte novú autentifikáciu a novú reláciu aplikácie po presune, pretože klientske prepnutie nie je prepnutie so stavom a dlhé relácie ho neprežijú.
Jedna adresa u dvoch poskytovateľov je iný produkt
Udržať jednu verejnú adresu dostupnú cez oba okruhy je služba smerovania, nie zaškrtávacie pole vo VPN. Vyžaduje adresný priestor, ktorý sú obaja poskytovatelia ochotní prenášať, ohlásený tak, aby ho ich siete prijali, a to je presne to, čo poskytuje multihoming s priestorom nezávislým od poskytovateľa a BGP. Priradenie adresy ISP A rozhraniu ISP B vás tam nedostane; paket príde do siete, ktorá tento prefix nikdy neohlásila, a je zahodený vyššie v sieti.
Na zverejnenie dvoch vstupov nič z toho nepotrebujete. Ak klient dokáže držať dva názvy a prepínať medzi nimi, dva nezávislé vstupy stačia a vyhnete sa číslu AS, dohode o peeringu a prefixu, ktorý musí byť prijatý všade. Možnosť prenosnej adresy zvážte len vtedy, keď skutočne potrebujete jeden stabilný vstupný bod, ktorý klienti nemôžu nahradiť prekonfigurovaním, alebo keď je prepnutie založené na DNS s oneskorením TTL príliš pomalé pre výpadok, na ktorý projektujete.
Čo skontrolovať ďalej
Postupujte smerom von od zlyhávajúceho vstupu v tomto poradí: odpovedá druhá adresa zvonku, predkladá identitu, ktorú klient očakáva, odchádza odpoveď tou cestou, ktorou prišla požiadavka, a dokáže sa klient dozvedieť názov skôr, než ho potrebuje. Kde je odpoveď nie, opravte tú vrstvu a otestujte znova s nasadeným profilom, nie s testovacím hostiteľom, pretože nadviazanie spojenia z laboratória dokazuje menej než dokončené spojenie skutočného klienta.
Vedzte krátky záznam pre každú WAN s adresou, portom, ukončujúcim rozhraním, názvom certifikátu, spiatočnou cestou a prekladovým pravidlom a znovu ho overte vždy, keď sa zmení okruh, zariadenie NAT alebo verzia klienta. Nevyužité záložné cesty ticho hnijú: nič neupozorní na vstup, ktorý nikto nepoužíva, až do dňa, keď na ňom všetci závisia.