A második WAN VPN-belépés meghiúsul, miközben az elsődleges tovább működik

Az elsődleges alagút állva marad, a felhasználók dolgoznak tovább, a második ISP-kör pedig tétlenül áll, bármit is változtat. Közzétettél egy címet a tartalék körhöz, rámutattál egy névvel, talán hozzáadtál egy tartalék bejegyzést a klienshez, és a kliens vagy soha nem próbálja, vagy hitelesít, majd meghal. Az általam követett esetekben a feladatátvétel funkció általában rendben volt; ami hiányzott, az az öt dolog egyike volt, amelyek használhatóvá tesznek egy bejegyzést. Egy név feloldódhat a tartalék címre, miközben semmi sem figyel azon az interfészen, és egy listener elfogadhat kapcsolatot, miközben a válasz az elsődlegesen keresztül távozik. Kezeld minden WAN-t külön bejegyzésként, saját szerződéssel, és a hiba megszűnik klienshibának látszani.

Minden WAN-nak saját bejegyzésszerződésre van szüksége

Rögzíts WAN-onként öt mezőt: a nyilvános nevet és címet, a szállítást és portot, az őt lezáró interfészt vagy kontextust, a bemutatandó partneridentitást, és azt, hogy honnan távozik a válasz. Két kör két teljes készletet jelent. Ha a második készletnek nincs lezáró interfésze vagy visszatérési útja, nincs tartalék bejegyzésed; van egy DNS-rekordod, amely szándékot ír le.

Az eszköznek és verziójának is támogatnia kell ezt az elrendezést. Egy DNS-rekord nem tud szolgáltatást nyitni egy másik interfészen, és sok platformon a listenert címenként, nem eszközönként konfigurálják. Az ASA interfészalapú IPsecje a kriptotérképeket és alagútcsoportokat a külső interfészhez köti, ezért a második uplinknek ott kell házirendet kapnia, ahol ezek a csomagok valóban megérkeznek. Az útalapú tervek másképp viselkednek: a listener minden címhez vagy egy megnevezett címhez kötődhet, és ez a választás dönti el, hogy az ISP B egyáltalán válaszolhat-e.

Ellenőrizd, hogy a második WAN valóban válaszol-e

Mindkét körön kívülről tesztelj, ne a gateway mögötti gépről, és pontosan azt a nevet teszteld, amelyet a kliensprofil használ. TLS-listener esetén a gyors ellenőrzés a openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts , amelyet a hálózatodon kívüli hosztról futtatsz. Befejezett kézfogást szeretnél, amelynek lánca megfelel a profilban lévő névnek, nem csupán egy TCP-portot, amely elfogad egy kapcsolatot.

RFC 9525 elmagyarázza, mit ellenőriz a kliens: az identitást, amelyet el akart érni, összevetve a szolgáltatás által bemutatott tanúsítvánnyal. Az a második bejegyzés, amely az elsődleges bejegyzés tanúsítványát adja vissza, vagy egy alapértelmezett tanúsítvány, amely egyik nevet sem sorolja fel, megbukik ezen a teszten, pedig a port nyitva van, és a tűzfal engedi.

Két minta magyarázza a legtöbb hibát itt. A lógó kapcsolat általában azt jelenti, hogy nincs listener azon az interfészen, egy hozzáférési szabály csak az elsődleges alhálózatokat engedi, vagy a második kör előtti szolgáltatói eszköz eldobja a portot. A rossz identitással végződő kézfogás általában más trustpointot, alapértelmezett virtuális hostot vagy az elsődlegesről identitás-módosítás nélkül átmásolt konfigurációt jelent.

Kövesd a választ, ne csak a kérést

A második WAN általában visszafelé törik el. A kérés az ISP B felől érkezik, az eszköz válaszol, és a válasz az ISP A alapértelmezett útvonalán távozik olyan forráscímmel, amelyet a kliens soha nem kért. Az állapotfüggő fordítás rontja a helyzetet: ha a leképezés az elsődleges interfészhez készült, a visszatérő csomag kihagyja a fordítást, vagy olyan forrást hordoz, amelyet a kliens tűzfala eldob. A szolgáltatók azokat a forráscímeket is eldobják, amelyek nem ahhoz a körhöz tartoznak, amelyet adtak neked, ezért ez egyirányú fekete lyuknak látszik, nem tiszta protokollhibának.

Ellenőrizd az útválasztási döntést a második bejegyzésből származó forgalomra. A válasznak azon az interfészen kell távoznia, amelyen a kérés érkezett, vagy legalább olyan címet kell hordoznia, amelyet a távoli fél ehhez az útvonalhoz tartozónak fogad el. Szabályzatvezérelt útválasztású platformokon ez az érkező interfészhez vagy a lefordított forráshoz kötött szabályt jelent, valamint minden külső interfészhez kötött fordítási utasítást. Rögzíts egyszerre mindkét interfészen, miközben a kliens csatlakozik; az ISP B-n érkező SYN és az ISP A-n távozó SYN-ACK egyetlen futásban eldönti a kérdést.

Adj a kliensnek módot, hogy értesüljön a második bejegyzésről

A feladatátvétel kliensoldali döntés, és minden klienscsalád másképp értesül az alternatívákról. ASA-n a tartalék-kiszolgálók listáját a csoportházirend webvpn attribútumai adják át, míg más kliensek a profilon belüli listát vagy a felhasználó által választott kézi második profilt várják. A Cisco kapcsolatházirend-útmutatója leírja a kliensben beállított és az átjáró által biztosított tartalék információt is, és ezeket a protokollspecifikus részleteket nem szabad minden kliensre vagy alagút módra általánosítani. Erősítsd meg, melyik mechanizmust valósítja meg a telepített kliens, mielőtt a második bejegyzést a rossz köré építenéd.

Bármilyen mechanizmus is legyen, a kliensnek fel kell tudnia oldani az alternatív nevet, mielőtt elveszíti az elsődleges útvonalat. Ezt a függőséget szokták kihagyni: ha a tartalék nevet olyan feloldó válaszolja meg, amely csak azon az alagúton érhető el, amely épp most esett ki, a tartalék el sem tud indulni. Tedd közzé a második nevet egy olyan feloldóban, amely helyben vagy az interneten keresztül válaszol. Számíts új hitelesítésre és új alkalmazás-munkamenetre az áttérés után, mert a kliens feladatátvétele nem állapotfüggő feladatátvétel, és a hosszú munkamenetek nem élik túl.

Egy cím két szolgáltatónál más termék

Egyetlen nyilvános cím elérhetően tartása mindkét körön keresztül útválasztási szolgáltatás, nem pipa a VPN-ben. Olyan címterület kell hozzá, amelyet mindkét szolgáltató hajlandó hordozni, olyan formában hirdetve, amelyet a hálózataik elfogadnak, és ezt adja a szolgáltatófüggetlen térrel és BGP-vel működő multihoming. Az ISP A címe nem vezet oda, ha az ISP B interfészére osztod; a csomag olyan hálózathoz érkezik, amely soha nem hirdette a prefixet, és felfelé eldobják.

Semmi ilyesmire nincs szükséged két bejegyzés közzétételéhez. Ha a kliens két nevet tud tartani, és tud közöttük átváltani, két független bejegyzés elég, és elkerülöd az AS-számot, a peering-megállapodást és a mindenhol elfogadandó prefixet. A hordozható cím lehetőségét csak akkor fontold meg, ha valóban szükséged van egyetlen stabil belépési pontra, amelyet a kliensek nem tudnak átkonfigurálni a lecseréléséhez, vagy ha a DNS-alapú feladatátvétel a TTL-késleltetésével túl lassú ahhoz a kieséshez, amelyre tervezel.

Mit ellenőrizz következőként

A hibás bejegyzéstől kifelé haladj ebben a sorrendben: válaszol-e a második cím kívülről, bemutatja-e azt az identitást, amelyet a kliens vár, a kérés érkezési útján távozik-e a válasz, és meg tudja-e tanulni a kliens a nevet, mielőtt szüksége lenne rá. Ahol a válasz nem, javítsd azt a réteget, és a telepített profillal teszteld újra, ne teszt-hoszttal, mert a laboratóriumi kézfogás kevesebbet bizonyít, mint a valódi kliens befejezett kapcsolata.

Vezess rövid feljegyzést WAN-onként a címmel, porttal, lezáró interfésszel, tanúsítványnévvel, visszatérési úttal és fordítási szabállyal, és ellenőrizd újra minden kör-, NAT-eszköz- vagy kliensverzió-változáskor. A tétlen tartalék útvonalak csendben elrohadnak: semmi sem figyelmeztet arra a bejegyzésre, amelyet senki nem használ, egészen addig a napig, amikor mindenki rá van utalva.