Doodskakelaar vir ’n VPN-sywa: blokkeer verkeer wanneer dit uitval

’n Toepassingshouer wat ’n VPN-houer se netwerknaamruimte deel, het geen eie koppelvlak nie, so dit is maklik om te aanvaar dat dit niks kan stuur wanneer die tonnel faal nie. Daardie aanname is verkeerd in die foutmodus wat saak maak. As die VPN-proses sterf terwyl die naamruimte bly voortbestaan, behou die toepassing sy sokkette en behou die naamruimte sy roetes, en verkeer gaan voort op watter pad ook al nog geïnstalleer is. ’n Ware doodskakelaar is ’n eksplisiete filterbeleid plus toetse van die looptyd se lewensiklus, nie ’n beginafhanklikheid nie.

Waarom die deel van ’n naamruimte nie ’n doodskakelaar is nie

Om ’n naamruimte te deel beteken die app gebruik die VPN-houer se koppelvlakke, adresse en roetetabel. Dit verwyder die app se onafhanklike pad na die netwerk terwyl die gedeelde naamruimte ongeskonde is, en dit sê niks oor wat daardie naamruimte sal doen wanneer die tonnel weggaan nie.

Compose-afhanklikheidsvoorwaardes kan ’n app se begin uitstel totdat ’n afhanklikheid gesond is. Dit dek een oomblik in tyd en geen latere faling nie, so dit is ’n hulpmiddel vir beginvolgorde eerder as ’n deurlopende uitgangsbrandmuur.

Wat werklik gebeur wanneer die houer afsluit

Onderskei drie gebeure. Die VPN-proses binne die houer kan sterf terwyl die houer aanhou loop. Die houer kan stop of verwyder word, wat die naamruimte vernietig. Die houer kan herskep word, wat ’n nuwe naamruimte en nuwe reëls bou.

In die eerste geval bly die naamruimte voortbestaan, die verstekroete kan steeds na die fisiese koppelvlak wys, en die toepassing hou aan om direk te stuur. In die tweede geval verloor die afhanklike app gewoonlik heeltemal konnektiwiteit, omdat sy naamruimte verdwyn het. In die derde geval kan die app weer aan ’n vars naamruimte koppel voordat die tonnel gereed is. Elke geval het ’n ander toets nodig, en ’n ontwerp wat net die ordelike ontkoppeling dek, dek die oninteressantste een.

Bou ’n eksplisiete uitgangsbeleid

Skryf die beleid binne die gedeelde naamruimte sodat dit op die toepassing se pakkette van toepassing is. Die vorm is ’n verstekverwerping met smal uitsonderings: loopback, die tonnelkoppelvlak, en die spesifieke eindpuntadres en -poort wat die tonnelvervoer nodig het.

Die eindpunt-uitsondering moet in plek wees voordat die tonnel op is, anders kan die VPN-kliënt nie sy bediener bereik nie. Dit is waarom die reëlversameling die buitenste vervoer eksplisiet toelaat eerder as om die fisiese koppelvlak in die algemeen toe te laat. Voeg ook IPv6-reëls by as die naamruimte IPv6-verbinding het, want ’n slegs-IPv4-beleid laat die ander familie oop.

DNS hoort ook in die beleid. As die app name oplos deur ’n oplosser wat net binne die tonnel bereikbaar is, sal die verwerpingsreël oplossing breek wanneer die tonnel af is, wat die korrekte gedrag vir ’n doodskakelaar is. Besluit doelbewus of dit is wat jy wil hê.

Toets die lewensiklus, nie net die ontkoppeling nie

Stuur ’n vars onskadelike versoek terwyl die tonnel gesond is, dood dan die VPN-proses en stuur nog een. Herhaal dit ná ’n houerstop, ná ’n herstart en ná herskeping. ’n Vars versoek maak saak omdat ’n bestaande verbinding ’n reëlverandering kan oorleef wat nuwe verbindings blokkeer.

Moenie op ’n gesondheidstoets of ’n uitgang-IP-opsoeking as die blokkeringsmeganisme staatmaak nie. ’n Toets waarneem toestand en rapporteer dit; ’n beleid beheer verkeer. Die twee hoort in dieselfde ontplooiing, en hulle is nie plaasvervangers nie.

Teken die reëls aan sodat die toets ’n opdatering oorleef

Skryf die verwagte uitkoms vir elke falinggeval in die ontplooiingsdokumentasie, saam met die reëls wat dit implementeer. Daardie rekord laat dieselfde toets loop ná ’n beeldopdatering of ’n looptyd-opgradering, wanneer naamruimtegedrag of verstekroetes kan verander sonder dat iemand die compose-lêer wysig.

Hou die VPN-eindpunt se vereiste buitenste pad apart van onbeperkte toepassingsuitgang, en hou DNS en IPv6 binne die beoogde dekking. As die beleid die hele fisiese koppelvlak vir gerief toelaat, is die doodskakelaar weg. Die Docker-netwerkdokumentasie beskryf die gedeelde-naamruimte-reëling waarop die beleid gebou is, en dit is die verwysing om na te gaan wanneer die looptyd se gedrag betwyfel word.