Tweede WAN-VPN-inskrywing misluk terwyl die primêre steeds werk

Die primêre tonnel bly op, gebruikers werk aan, en die tweede ISP-baan sit ledig ongeag wat jy verander. Jy het 'n adres vir die rugsteunbaan gepubliseer, 'n naam daarheen laat wys, miskien 'n rugsteuninskrywing by die kliënt gevoeg, en die kliënt probeer dit óf nooit óf verifieer en sterf dan. In die gevalle wat ek nagegaan het, was die oorskakelingsfunksie gewoonlik reg; wat ontbreek het, was een van die vyf dinge wat 'n inskrywing bruikbaar maak. 'n Naam kan na die rugsteunadres wys terwyl niks op daardie koppelvlak luister nie, en 'n luisteraar kan 'n verbinding aanvaar terwyl die antwoord deur die primêre een vertrek. Behandel elke WAN as 'n aparte inskrywing met sy eie kontrak, dan lyk die fout nie meer soos 'n kliëntfout nie.

Elke WAN het sy eie inskrywingskontrak nodig

Teken vyf velde per WAN aan: die publieke naam en adres, die transport en poort, die koppelvlak of konteks wat dit termineer, die eweknie-identiteit wat dit moet voorhou, en waar die antwoord vertrek. Twee bane beteken twee volledige stelle. As die tweede stel geen terminerende koppelvlak of geen terugroete het nie, het jy nie 'n rugsteuninskrywing nie; jy het 'n DNS-rekord wat 'n bedoeling beskryf.

Die toestel en sy weergawe moet ook die reëling ondersteun. 'n DNS-rekord kan nie 'n diens op 'n ander koppelvlak oopmaak nie, en op baie platforms word die luisteraar per adres eerder as per toestel gekonfigureer. Koppelvlakgebaseerde IPsec op 'n ASA bind kriptokaarte en tonnelgroepe aan die buitekoppelvlak, so 'n tweede opvoer het beleid nodig waar daardie pakkette werklik aankom. Roetegebaseerde ontwerpe werk anders: die luisteraar kan aan elke adres of aan een genoemde adres bind, en daardie keuse bepaal of ISP B hoegenaamd kan antwoord.

Kontroleer of die tweede WAN werklik antwoord

Toets van buite albei bane, nie van 'n masjien agter die poort nie, en toets die presiese naam wat die kliëntprofiel gebruik. Vir 'n TLS-luisteraar is die vinnige kontrole openssl s_client -connect ADDRESS:443 -servername vpn.example.com -showcerts wat jy vanaf 'n gasheer buite jou netwerk uitvoer. Jy wil 'n voltooide handdruk hê waarvan die ketting by die naam in die profiel pas, nie bloot 'n TCP-poort wat 'n verbinding aanvaar nie.

RFC 9525 verduidelik wat die kliënt nagaan: die identiteit wat hy bedoel het om te bereik, vergelyk met die sertifikaat wat die diens voorhou. 'n Tweede inskrywing wat die primêre inskrywing se sertifikaat teruggee, of 'n versteksertifikaat wat nie een van die name lys nie, faal hierdie toets selfs al is die poort oop en laat die brandmuur dit toe.

Twee patrone verduidelik die meeste foute hier. 'n Verbinding wat hang, beteken gewoonlik geen luisteraar op daardie koppelvlak nie, 'n toegangsreël wat net die primêre subnetten toelaat, of 'n draertoestel voor die tweede baan wat die poort laat val. 'n Handdruk wat met die verkeerde identiteit eindig, beteken gewoonlik 'n ander trustpoint, 'n verstek virtuele gasheer, of konfigurasie wat van die primêre gekopieer is sonder om die identiteit aan te pas.

Volg die antwoord, nie net die versoek nie

Die tweede WAN breek gewoonlik op die terugpad. 'n Versoek kom op ISP B aan, die toestel antwoord, en die antwoord vertrek deur die verstekroete op ISP A met 'n bronadres wat die kliënt nooit gevra het nie. Toestandvolle vertaling maak dit erger: as die kartering vir die primêre koppelvlak gebou is, mis die terugkerende pakket die vertaling of dra 'n bron wat die kliënt se brandmuur weggooi. Verskaffers laat ook bronadresse val wat nie aan die baan behoort wat hulle aan jou gegee het nie, en daarom lyk dit soos 'n eenrigting-swartgat eerder as 'n skoon protokolfout.

Kontroleer die roetebesluit vir verkeer wat van die tweede inskrywing afkomstig is. Die antwoord moet die koppelvlak verlaat waarop die versoek aangekom het, of ten minste 'n adres dra wat die ver kant as aan daardie pad behorend aanvaar. Op beleidsroeterende platforms beteken dit 'n reël wat aan die inkomende koppelvlak of die vertaalde bron gekoppel is, plus 'n vertalingsverklaring wat aan elke buitekoppelvlak gebind is. Neem gelyktydig op albei koppelvlakke op terwyl die kliënt verbind; 'n SYN wat op ISP B aankom met die SYN-ACK wat op ISP A vertrek, beslis die vraag in een lopie.

Gee die kliënt 'n manier om van inskrywing twee te leer

Oorskakeling is 'n kliëntkant-besluit, en elke kliëntfamilie leer anders van alternatiewe. Op 'n ASA word die rugsteunbedienerlys deur die groepbeleid se webvpn-kenmerke gelewer, terwyl ander kliënte 'n lys in die profiel verwag of 'n handmatige tweede profiel wat die gebruiker kies. Cisco se verbindingsbeleidsgids beskryf beide kliëntgekonfigureerde en poortverskafde rugsteuninligting, en daardie protokolspesifieke besonderhede moet nie na elke kliënt of tonnelmodus veralgemeen word nie. Bevestig watter meganisme die ontplooide kliënt implementeer voordat jy die tweede inskrywing rondom die verkeerde een bou.

Wat die meganisme ook al is, die kliënt moet die alternatiewe naam kan oplos voordat hy die primêre pad verloor. Daardie afhanklikheid is die een wat mense miskyk: as die rugsteunnaam beantwoord word deur 'n oplosser wat net deur die tonnel bereikbaar is wat pas gefaal het, kan die terugval nie eers begin nie. Publiseer die tweede naam in 'n oplosser wat plaaslik of oor die internet antwoord. Verwag 'n nuwe verifikasie en 'n nuwe toepassingsessie ná die skuif, want kliëntoorskakeling is nie toestandvolle oorskakeling nie en langdurige sessies oorleef dit nie.

Een adres op twee verskaffers is 'n ander produk

'n Enkele publieke adres bereikbaar deur albei bane hou, is 'n roetediens, nie 'n blokkie op die VPN nie. Dit het adresruimte nodig wat albei verskaffers bereid is om te dra, aangekondig op 'n manier wat hulle netwerke aanvaar, en dit is wat multihoming met verskafferonafhanklike ruimte en BGP bied. Om ISP A se adres aan die ISP B-koppelvlak toe te wys, kom nie daar nie; die pakket kom by 'n netwerk aan wat nooit die voorvoegsel geadverteer het nie en word stroomop laat val.

Jy het niks daarvan nodig om twee inskrywings te publiseer nie. As die kliënt twee name kan hou en tussen hulle kan oorskakel, is twee onafhanklike inskrywings genoeg, en jy vermy 'n AS-nommer, 'n peering-reëling en 'n voorvoegsel wat oral aanvaar moet word. Oorweeg die draagbare-adres-opsie net wanneer jy werklik een stabiele inskrywpunt nodig het wat kliënte nie herkonfigureer kan word om te vervang nie, of wanneer DNS-gebaseerde oorskakeling met sy TTL-vertraging te stadig is vir die onderbreking waarteen jy ontwerp.

Wat om volgende te kontroleer

Werk van die falende inskrywing uitwaarts in hierdie volgorde: antwoord die tweede adres van buite, hou dit die identiteit voor wat die kliënt verwag, verlaat die antwoord die pad waarlangs die versoek aangekom het, en kan die kliënt die naam leer voordat hy dit nodig het. Waar 'n antwoord nee is, maak daardie laag reg en toets weer met die ontplooide profiel eerder as 'n toetsgasheer, want 'n handdruk uit die laboratorium bewys minder as 'n voltooide verbinding van die werklike kliënt.

Hou 'n kort rekord per WAN, met adres, poort, terminerende koppelvlak, sertifikaatnaam, terugroete en vertalingsreël, en kontroleer dit weer wanneer 'n baan, 'n NAT-toestel of 'n kliëntweergawe verander. Ledige rugsteunpaaie verrot stilweg: niks waarsku oor die inskrywing wat niemand gebruik nie tot die dag wanneer almal daarvan afhanklik is.