Twadde WAN-VPN-yngong mislearret wylst de primêre noch wurket

De primêre tunnel bliuwt oan, brûkers wurkje troch, en it twadde ISP-sirkwy stiet stil, wat jo ek feroarje. Jo hawwe in adres publisearre foar it reserve-sirkwy, in namme dêrop rjochte, miskien in reserve-yngong tafoege oan 'e client, en de client besiket it of nea of autentisearret en stjert dan. Yn 'e gefallen dy't ik folge haw, wie de failover-funksje meastentiids yn oarder; wat ûntbruts wie ien fan 'e fiif dingen dy't in yngong brûkber meitsje. In namme kin nei it reserve-adres oplosse wylst der neat op dy interface harket, en in listener kin in ferbining oannimme wylst it antwurd fia de primêre fuortgiet. Behannelje elke WAN as in aparte yngong mei syn eigen kontrakt en de flater liket net mear op in client-bug.

Elke WAN hat syn eigen yngongskontrakt nedich

Skriuw fiif fjilden per WAN op: de iepenbiere namme en it adres, it ferfier en de poarte, de interface of kontekst dy't it beëiniget, de identiteit fan 'e partner dy't it presintearje moat, en wêr't it antwurd fuortgiet. Twa sirkwys betsjutte twa folsleine sets. As de twadde set gjin beëinigjende interface of gjin weromwei hat, hawwe jo gjin reserve-yngong; jo hawwe in DNS-record dy't in bedoeling beskriuwt.

It apparaat en syn ferzje moatte ek dizze opstelling stypje. In DNS-record kin gjin tsjinst op in oare interface iepenje, en op in soad platfoarmen wurdt de listener per adres ynsteld ynstee fan per apparaat. Interface-basearre IPsec op in ASA bynt krypto-kaarten en tunnelgroepen oan 'e bûtenste interface, dus in twadde uplink hat belied nedich dêr't dy pakketten echt oankomme. Rûte-basearre ûntwerpen gedrage har oars: de listener kin oan elke adres of oan ien neamde adres bine, en dy kar beslút oft ISP B hielendal antwurdzje kin.

Kontrolearje oft de twadde WAN echt antwurdet

Test fan bûten beide sirkwys, net fan in masine efter de gateway, en test de krekte namme dy't it client-profil brûkt. Foar in TLS-listener is de snelle kontrôle openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts útfierd fan in host bûten jo netwurk. Jo wolle in foltôge handshake wêrfan de keatling by de namme yn it profil past, net samar in TCP-poarte dy't in ferbining oannimt.

RFC 9525 ferklearret wat de client kontrolearret: de identiteit dy't er berikke woe, fergelike mei it sertifikaat dat de tsjinst presintearret. In twadde yngong dy't it sertifikaat fan 'e primêre yngong weromjout, of in standertsertifikaat dat gjin fan beide nammen listet, falt foar dizze test, ek al is de poarte iepen en lit de firewall it ta.

Twa patronen ferklearje de measte flaters hjir. In ferbining dy't hingje bliuwt betsjut meastentiids gjin listener op dy interface, in tagongsregel dy't allinnich de primêre subnetten tastiet, of in apparaat fan 'e oanbieder foar it twadde sirkwy dat de poarte falle lit. In handshake dy't mei de ferkearde identiteit einiget betsjut meastentiids in oar trustpoint, in standert firtueel host, of konfiguraasje kopyearre fan 'e primêre sûnder de identiteit oan te passen.

Folgje it antwurd, net allinnich it fersyk

De twadde WAN brekt meastentiids op 'e weromwei. In fersyk komt fia ISP B, it apparaat antwurdet, en it antwurd giet fia de standertrûte op ISP A fuort mei in boarne-adres dat de client nea frege hat. Steatfoller oersetting makket it slimmer: as de mapping foar de primêre interface boud is, mist it weromkommende pakket de oersetting of draacht in boarne dy't de firewall fan 'e client fuortsmyt. Oanbieders smite ek boarne-adressen fuort dy't net by it sirkwy hearre dat se jo joegen, en dêrom liket dit op in ienrjochting swart gat ynstee fan in skjinne protokolfout.

Kontrolearje de rûtebeslissing foar ferkear dat fan 'e twadde yngong komt. It antwurd moat de interface ferlitte dêr't it fersyk op oankaam, of teminsten in adres drage dat de fiere kant akseptearret as hearrend by dat paad. Op platfoarmen mei beliedsrûtering betsjut dat in regel keppele oan 'e ynkommende interface of it oersetten boarne, plus in oersettingsferklearring bûn oan elke bûtenste interface. Fange tagelyk op beide interfaces wylst de client ferbynt; in SYN dy't op ISP B oankomt mei de SYN-ACK dy't op ISP A fuortgiet, besljochtet de fraach yn ien run.

Jou de client in manier om fan yngong twa te learen

Failover is in beslissing oan 'e clientkant, en elke clientfamylje leart oer alternativen oars. Op in ASA wurdt de reserve-tsjinnerlist levere fia de webvpn-attributen fan it groepbelied, wylst oare clients in list yn it profil ferwachtsje of in hânmjittich twadde profil dat de brûker kiest. De Cisco-gids foar ferbiningsbelied beskriuwt sawol yn 'e client konfigurearre as troch de gateway levere reserve-ynformaasje, en dy protokolspezifike details moatte net generalisearre wurde nei elke client of tunnelmodus. Befêstigje hokker meganisme de útrôle client ymplementearret foar't jo de twadde yngong om it ferkearde hinne bouwe.

Hokker meganisme dan ek, de client moat de alternative namme oplosse kinne foar't er it primêre paad ferliest. Dy ôfhinklikens is dejinge dy't minsken misse: as de reserve-namme beantwurde wurdt troch in resolver dy't allinnich fia de tunnel berikber is dy't krekt mislearre, kin de fallback hielendal net begjinne. Publisearje de twadde namme yn in resolver dy't lokaal of oer it ynternet antwurdet. Ferwachtsje in nije autentikaasje en in nije applikaasjesesje nei de ferhuzing, want client-failover is gjin steatfoller failover en langduorjende sesjes oerlibje it net.

Ien adres by twa oanbieders is in oar produkt

Ien iepenbier adres berikber hâlde fia beide sirkwys is in rûtsjinst, gjin oanfinkfakje yn 'e VPN. It hat adresromte nedich dy't beide oanbieders bereid binne te dragen, oankundige op in manier dy't har netwurken akseptearje, en dat is wat multihoming mei oanbiederonôfhinklike romte en BGP jout. It adres fan ISP A tawize oan 'e interface fan ISP B liedt dêr net hinne; it pakket komt by in netwurk dat it foarheaksel nea oankundige hat en wurdt streamop fuortsmiten.

Jo hawwe neat fan dat alles nedich om twa yngongen te publisearjen. As de client twa nammen hâlde kin en tusken har beiden falle kin, binne twa ûnôfhinklike yngongen genôch, en jo foarkomme in AS-nûmer, in peering-oerienkomst en in foarheaksel dat oeral akseptearre wurde moat. Oerweeg de opsje foar draachber adres allinnich as jo echt ien stabyl yngongspunt nedich hawwe dat clients net omkonfigurearje kinne om it te ferfangen, of as DNS-basearre failover mei syn TTL-fertraging te stadich is foar de útfal dêr't jo tsjin ûntwerpe.

Wat hjirnei te kontrolearjen

Wurkje fan 'e mislearre yngong nei bûten ta yn dizze folchoarder: antwurdet it twadde adres fan bûten, presintearret it de identiteit dy't de client ferwachtet, giet it antwurd fuort fia it paad dêr't it fersyk oankaam, en kin de client de namme leare foar't er it nedich hat. Wêr't it antwurd nee is, reparearje dy laach en test opnij mei it útrôle profil ynstee fan in testhost, want in handshake út it laboratoarium bewissiget minder as in foltôge ferbining fan 'e echte client.

Hâld in koarte notysje per WAN, mei adres, poarte, beëinigjende interface, sertifikaatnamme, weromwei en oersettingsregel, en kontrolearje dy opnij wannear't in sirkwy, in NAT-apparaat of in clientferzje feroaret. Ydle reservepaden fergrieme stil: neat warskôget oer de yngong dy't nimmen brûkt oant de dei dat elkenien derfan ôfhinklik is.