Geneste VPN: watter tonnel dra die buitenste verbinding?

Twee VPN-kliënte wat gelyktydig loop, lewer nie ’n geneste tonnel nie; hulle lewer twee tonnels en ’n rusie oor die roetering. ’n Geneste tonnel bestaan wanneer die binneste kliënt se verbinding na sy eie bediener self deur die buitenste tonnel gedra word, en dit is ’n reëling wat jy doelbewus bou. Kry dit reg en die binneste bediener sien die buitenste bediener se adres; kry dit verkeerd en een kliënt herverbind stilweg om die ander. Drie voorwaardes bepaal of die nesteling werklik of toevallig is.

Drie voorwaardes bepaal die nesteling

Die eerste is watter eindpunt watter pad nodig het. Noem die binneste bediener se adres, noem die buitenste bediener se adres, en stel uitdruklik vas dat die binneste bediener net deur die buitenste tonnel bereikbaar is. Alles anders volg uit daardie sin, insluitend watter roetes in watter tabel hoort.

Die tweede is of jy die pad op elke laag kan sien. As jy die kern nie kan vra watter roete ’n spesifieke bestemming sou gebruik nie, lei jy die ketting af uit ’n finale uitgang-IP, en dit is presies die bewyse wat nesting nie van toeval kan onderskei nie.

Die derde is wat gebeur wanneer die buitenste tonnel wegval. Die binneste tonnel kan daarmee stop, oor die gewone netwerk herverbind of geblokkeer bly tot die buitenste pad terugkeer, en al drie is verdedigbare beleide. Hulle is nie dieselfde beleid nie, en die verstekgedrag van die meeste kliënte is die tweede. ’n Kliënt wat sy eindpunt oor die fisiese netwerk herverbind terwyl hy ’n gesonde verbinding wys, is die algemeenste manier waarop ’n bedoelde ketting stilweg twee onverwante tonnels word.

Voorwaarde een: watter eindpunt watter pad nodig het

ip route get 203.0.113.10 beantwoord daardie vraag direk: dit druk die roete, die bronadres en die koppelvlak wat die kern nou vir daardie bestemming sou gebruik.

Voer dit vir die binneste bediener uit voordat die binneste kliënt begin en weer daarna, en vergelyk. As die antwoord van die fisiese koppelvlak na die buitenste tonnel se koppelvlak verander, is die nesteling op daardie oomblik werklik. As dit nie verander nie, verbind die binneste kliënt direk, ongeag wat die paneelbord sê. Herhaal dit vir die buitenste bediener se adres, wat steeds deur die fisiese koppelvlak opgelos moet word, want ’n roete wat beide eindpunte rekursief vang is die fout wat die masjien heeltemal van die netwerk af haal.

Voorwaarde twee: ondersoek die pad op elke laag

Roetekeuse is meer as die hoofdtabel op ’n moderne kliënt. Beleidsreëls kan gemerkte pakkette na ’n ander tabel stuur, ’n kliënt kan sy sok aan ’n koppelvlak bind, en ’n houer of naamruimte het heeltemal eie tabelle. Met ip rule en ip route show table all vind jy uit watter van dié in die spel is.

’n Kliënt wat SO_MARK op sy eie sok stel, of so opgestel is dat hy aan ’n spesifieke toestel bind, omseil die verstekroete wat jy gedink het jy het gereël. Dit is ’n funksie en nie ’n fout nie, en dit beteken die enigste betroubare kontrole is een wat in dieselfde naamruimte as die kliënt loop. As die kliënte in houers loop, voer die kontroles in daardie houers uit eerder as op die gasheer.

Voorwaarde drie: wat gebeur wanneer die buitenste tonnel wegval

Foutgedrag vereis ’n besluit, nie ’n verstek nie. Skryf neer wat met die binneste tonnel moet gebeur wanneer die buitenste verdwyn, en kry dan die kliënte om dit te doen.

Die opsies is konkreet. Om die binneste kliënt te stop wanneer die buitenste pad verdwyn, gee ’n skoon ketting en ’n duidelike onderbreking. Om hom direk te laat herverbind, gee beskikbaarheid en verwyder stilweg die eienskap waarvoor die ketting gebou is. Om te blokkeer tot die buitenste pad terugkeer, is die strengste en die lastigste om te bedryf, want elke flikkering van die buitenste tonnel word ’n sigbare voorval.

Toets al drie met onskadelike verkeer en ’n doelbewuste onderbreking van die buitenste tonnel, want om die opstelling te lees sê jou nie watter een jy het nie. Dood die buitenste tonnel, kyk wat die binneste kliënt doen, en kontroleer die roete weer terwyl dit af is. Bring die buitenste tonnel dan terug en bevestig dat die ketting weer vorm eerder as om die binneste kliënt op die direkte pad te laat wat hy intussen gekies het.

Wat die ketting jou nie gee nie

Ekstra lae voeg eindpunte, sleutels en foutmodusse by; hulle voeg geen anonimiteitswaarborg by nie, en hulle maak die buitenste operateur nie onvermoë om te sien dat daar ’n tonnel bestaan nie. Enige bewering oor waarteen nesting beskerm, moet die waarnemer noem waarteen dit beskerm.

Die lewering is ’n kort dokument en nie ’n werkende verbinding nie: watter eindpunt watter pad gebruik, wat by ’n onderbreking van die buitenste tonnel gebeur, en die drie opdragte wat die huidige toestand wys. die dokumentasie van strongSwan oor aanstuur is ’n nuttige verwysing vir hoe tonnelverkeer op ’n Linux-gasheer tussen koppelvlakke aangestuur word. Voer die kontroles weer uit ná elke kliëntopgradering, want die verstekke wat jou ketting geskep het, is nie ’n kontrak nie. ’n Geneste tonnel wat jy nie kan inspekteer nie, is ’n gerug met ’n statusliggie.