Önnur WAN VPN-færsla bregst þegar hin aðal virkar áfram

Aðalgöngin helst uppi, notendur halda áfram að vinna, og önnur ISP-línan situr aðgerðalaus hvað sem þú breytir. Þú birtir vistfang fyrir varalínuna, beindi nafni að því, bættir ef til vill varafærslu við biðlarann, og biðlarinn annaðhvort prófar hana aldrei eða auðkennir sig og deyr svo. Í þeim tilvikum sem ég hef rakið var failover-eiginleikinn venjulega í lagi; það sem vantaði var eitt af þeim fimm atriðum sem gera færslu nothæfa. Nafn getur leyst í varavistfangið á meðan ekkert hlustar á því viðmóti, og hlustari getur tekið við tengingu á meðan svarið fer út um aðalviðmótið. Líttu á hvert WAN sem aðskilda færslu með eigin samningi og bilunin hættir að líta út eins og villa í biðlaranum.

Hvert WAN þarf sinn eigin færslusamning

Skráðu fimm svæði fyrir hvert WAN: hið opinbera nafn og vistfang, flutninginn og portið, viðmótið eða samhengið sem lýkur henni, auðkenni jafningjans sem hún á að sýna, og hvaðan svarið fer út. Tvær línur þýða tvö heildarsett. Ef seinna settið hefur hvorki lokaviðmót né afturleið hefur þú ekki varafærslu; þú hefur DNS-færslu sem lýsir áformi.

Tækið og útgáfa þess verða líka að styðja þetta fyrirkomulag. DNS-færsla getur ekki opnað þjónustu á öðru viðmóti, og á mörgum kerfum er hlustarinn stilltur eftir vistfangi en ekki tæki. IPsec byggt á viðmóti á ASA bindur dulritunarkort og gönguhópa við ytra viðmótið, þannig að önnur upptenging þarf stefnu þar sem þessi pakkar koma í raun. Leiðamiðuð hönnun hegðar sér öðruvísi: hlustarinn getur bundist hverju vistfangi eða einu nafngreindu vistfangi, og sú ákvörðun ræður því hvort ISP B getur yfirhöfuð svarað.

Staðfestu að seinna WAN svari í raun

Prófaðu utan frá báðum línum, ekki frá vél bak við gáttina, og prófaðu nákvæmlega það nafn sem biðlarasniðið notar. Fyrir TLS-hlustara er fljótlega prófið openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts keyrt frá hýsli utan netsins þíns. Þú vilt lokið handaband þar sem keðjan passar við nafnið í sniðinu, ekki bara TCP-port sem tekur við tengingu.

RFC 9525 útskýrir hvað biðlarinn athugar: auðkennið sem hann ætlaði að ná, borið saman við vottorðið sem þjónustan sýnir. Önnur færsla sem skilar vottorði aðalfærslunnar, eða sjálfgefið vottorð sem listar ekkert nafnanna, fellur á þessu prófi þótt portið sé opið og eldveggurinn leyfi það.

Tvö mynstur útskýra flestar bilanir hér. Tenging sem hangir þýðir venjulega enginn hlustari á því viðmóti, aðgangsregla sem leyfir aðeins aðalnetin, eða burðartæki fyrir framan seinni línuna sem hendir portinu. Handaband sem endar með röngu auðkenni þýðir venjulega annan trustpoint, sjálfgefinn sýndarhýsil eða stillingar afritaðar frá aðalinu án þess að laga auðkennið.

Fylgdu svarinu, ekki bara beiðninni

Seinna WAN brotnar venjulega á leiðinni til baka. Beiðni kemur um ISP B, tækið svarar, og svarið fer út um sjálfgefna leið á ISP A með upprunavistfangi sem biðlarinn bað aldrei um. Ástandsbundin þýðing gerir það verra: ef vörpunin var byggð fyrir aðalviðmótið missir pakkinn sem kemur til baka þýðinguna eða ber uppruna sem eldveggur biðlarans hendir. Þjónustuveitendur henda líka upprunavistföngum sem tilheyra ekki línunni sem þeir gáfu þér, þess vegna lítur þetta út eins og einstefnu svarthol frekar en hrein prótókólvilla.

Athugaðu leiðarákvörðunina fyrir umferð sem á uppruna sinn í seinni færslunni. Svarið á að fara út um viðmótið sem beiðnin kom á, eða að minnsta kosti bera vistfang sem fjarlæga hliðin samþykkir sem tilheyrandi þeirri leið. Á kerfum með stefnuleiðsögn þýðir það reglu sem er bundin viðkomandi viðmóti eða þýdda upprunanum, auk þýðingaryfirlýsingar sem er bundin hverju ytra viðmóti. Taktu upp á báðum viðmótum samtímis á meðan biðlarinn tengist; SYN sem kemur á ISP B með SYN-ACK sem fer út á ISP A leysir spurninguna í einni keyrslu.

Gefðu biðlaranum leið til að læra um færslu tvö

Failover er ákvörðun á biðlarahlið og hver biðlarafjölskylda lærir um valkosti á sinn hátt. Á ASA er varaserverslistinn afhentur um webvpn-eiginleika hópstefnunnar, á meðan aðrir biðlarar búast við lista inni í sniðinu eða handvirkri annarri sniði sem notandinn velur. Leiðarvísir Cisco um tengistefnu lýsir bæði varaupplýsingum sem stilltar eru í biðlaranum og þeim sem gáttin veitir, og þessar prótókólsérstöku smáatriði eiga ekki að alhæfa yfir á hvern biðlara eða gönguham. Staðfestu hvaða aðferð biðlarinn sem er í notkun innleiðir áður en þú byggir seinni færsluna í kringum ranga aðferð.

Hver sem aðferðin er verður biðlarinn að geta leyst varanafnið áður en hann missir aðalleiðina. Þetta er háðin sem fólk missir: ef varanafnið er svarað af leysi sem er aðeins aðgengilegur um göngin sem féllu rétt í þessu getur varaleiðin ekki einu sinni byrjað. Birtu annað nafnið í leysi sem svarar staðbundið eða um internetið. Búðu þig við nýrri auðkenningu og nýrri forritalotu eftir flutninginn, því failover biðlarans er ekki ástandsbundið failover og langlífar lotur lifa það ekki af.

Eitt vistfang hjá tveimur veitendum er önnur vara

Að halda einu opinberu vistfangi aðgengilegu um báðar línur er leiðarþjónusta, ekki haka í VPN. Hún þarf vistfangsrými sem báðir veitendur eru tilbúnir að bera, tilkynnt á þann hátt sem net þeirra samþykkja, og það er það sem margtenging með rými óháðu veitanda og BGP veitir. Að úthluta vistfangi ISP A á viðmót ISP B kemur þér ekki þangað; pakkinn kemur að neti sem tilkynnti aldrei forskeytið og er hent ofar.

Þú þarft ekkert af þessu til að birta tvær færslur. Ef biðlarinn getur haldið tveimur nöfnum og skipt á milli þeirra duga tvær sjálfstæðar færslur, og þú sleppur við AS-númer, peering-samkomulag og forskeyti sem verður að samþykkja alls staðar. Íhugaðu valkostinn með flytjanlegu vistfangi aðeins þegar þú þarft virkilega einn stöðugan inngang sem ekki er hægt að stilla biðlara til að skipta út, eða þegar DNS-byggt failover með TTL-töfinni sinni er of hægt fyrir þá bilun sem þú hannar fyrir.

Hvað á að athuga næst

Vinndu út frá færslunni sem brást í þessari röð: svarar seinna vistfangið utan frá, sýnir það auðkennið sem biðlarinn á von á, fer svarið út um þá leið sem beiðnin kom, og getur biðlarinn lært nafnið áður en hann þarf á því að halda. Þar sem svarið er nei, lagaðu það lag og prófaðu aftur með sniðinu sem er í notkun en ekki prófunarhýsli, því handaband úr rannsóknarstofu sannar minna en lokin tenging raunverulega biðlarans.

Haltu stuttri skrá fyrir hvert WAN með vistfangi, porti, lokaviðmóti, vottorðsnafni, afturleið og þýðingarreglu, og athugaðu hana aftur í hvert sinn sem lína, NAT-tæki eða biðlaraútgáfa breytist. Aðgerðalausar varaleiðir fúna hljóðlega: ekkert varar við færslunni sem enginn notar fyrr en á þeim degi sem allir treysta á hana.