Waarom ’n volle tonnelroete die bediener afsny wat dit dra

Skakel ’n volle tonnel aan en elke bestemming behoort nou aan die VPN-koppelvlak, insluitend die masjien wat dit beëindig. Die buitenste pakkette wat die tonnel dra, is aan daardie masjien gerig, so die roete verteer uiteindelik die vervoer waarvan dit afhanklik is. Een ekstra spesifieke roete los dit op, en die rede is die moeite werd om te verstaan. Sonder daardie rede bring die volgende herbou die fout terug.

’n Roete wat sy eie vervoer opvreet

Enkapsulering draai elke pakket in ’n tweede kop. Die buitenste een word van die plaaslike fisiese adres na die bediener se publieke adres gerig, en dit moet die fisiese skakel oorsteek voordat enige tonnel kan bestaan.

Laat die opsoek vir daardie publieke adres nou die tonnel kies. Om die pakket te stuur, moet die masjien dit enkapsuleer, wat ’n roete na dieselfde adres vereis, wat die tonnel teruggee. Kliënte hanteer dit op een van twee maniere. ’n Sorgvuldige een weier om die verstekroete te installeer en rapporteer ’n fout, terwyl ’n minder sorgvuldige een sukses rapporteer en dan niks skuif nie. Die stille mislukking is die een wat ’n middag kos.

Die langste-voorvoegsel-passing bepaal die opsoek voordat enige maatstaf geraadpleeg word, so ’n enkeladres-roete oortref elke verstekroete op die masjien. Dit is die hele meganisme agter die herstel.

Installeer die uitsondering voor die verstek

Skep ’n enkeladres-roete vir die bediener, met die fisiese poort as die volgende sprong, voordat die verstekroete skuif. Orde maak saak: om dit daarna te installeer beteken om met ’n stukkende tonnel te leef terwyl jy tik.

Die meeste kliënte doen dit sonder aansporing. OpenVPN soek die afgeleë adres op en pen dit vas voordat dit die verstekpoort herskryf, en sy route-delay-opsie bestaan vir platforms waar daardie volgorde jaag. wg-quick volg ’n heeltemal ander pad, merk pakkette en raadpleeg ’n beleidsreël eerder as om ’n uitsondering by te voeg. Verskillende meganismes, dieselfde vereiste: die buitenste pakket moet ontsnap uit die tonnel wat dit skep.

ip route add 203.0.113.10/32 via 192.168.1.1 dev eth0
ip route get 203.0.113.10

Die opsoek-uitset is die aanvaardingstoets. Dit moet die fisiese toestel en die fisiese volgende sprong noem. ’n Tonneltoestel in daardie antwoord beteken die uitsondering ontbreek, of is geplaas ná iets wat dit oorheers.

Die spieëlbeeld op die bediener

Dieselfde lokval wag aan die ander kant, omgekeer. Gee die bediener ’n verstekroete deur ’n ander tonnel, of stuur vir hom ’n roete wat die kliënte se publieke adresse dek, en sy antwoorde kry ’n verkeerde-rigting-gewoonte.

Stel jou ’n kliënt voor wat konekteer en ’n versoek stuur. Die antwoord word aan daardie kliënt se publieke adres gerig, wat nou by ’n tonnelroete pas, so dit vertrek vanaf ’n ander koppelvlak met ’n bron wat die kliënt nooit geskakel het nie. Die kliënt kan daardie pakket ontvang en steeds verwerp, want niks bind dit aan die versoek wat hy gestuur het nie. Werk vanuit die bediener se roetebesluit eerder as vanuit die kliënt se tydsverloop, want net een van hulle wys die werklike keuse.

ip route get 198.51.100.44 from 10.90.0.1
ip rule show
sudo tcpdump -ni any host 198.51.100.44

Daar bestaan drie herstellings en hulle is nie gelyk nie. Om die diens aan die fisiese adres vas te pen, of om die bron te vertaal, verberg albei die roetebesluit in plaas daarvan om dit reg te stel. Om antwoordverkeer vir die tonnelpoel deur ’n toegewyde tabel te stuur, regstel die oorsaak, en die ander twee is net aanvaarbaar terwyl die roete-ontwerp gevries is.

Uitsonderings wat die tonnel aanhou steel

’n Handjievol take het die oop internet nodig selfs terwyl die tonnel die verstekroete besit, en elkeen het sy eie uitsondering nodig. Die dinamiese DNS-opdateerder is gewoonlik die eerste wat breek.

Dit los die verskaffer op, maak ’n verbinding oop, en vind sy eie pakkette wat deur ’n tonnel reis waarvan die adres sekondes gelede verander het, so die opdatering misluk of publiseer die verkeerde adres. Drie uitweë: pen die verskaffer vas met ’n gasheerroete deur die fisiese poort, hardloop die opdatering voordat die tonnel opkom, of gee die opdateerder ’n beleidstabel wat die tonnel nooit raak nie. Tydsynchronisering het dieselfde blootstelling op ’n toestel wat sonder ’n oplosser opstart, en sertifikaatvaliderings-eindpunte hoort om dieselfde rede op die lys.

’n Uitsondering wat niemand neergeskryf het nie, is ’n uitsondering wat die volgende herbou stilweg sal laat val.

Bewys dit ná ’n herverbinding, nie voor nie

Toets drie bestemmings, nie een nie: die eindpunt, ’n private adres agter die tonnel, en ’n publieke adres anderkant dit. ’n Enkele geslaagde opsoek sê byna niks oor die ander twee.

ip route get 203.0.113.10
traceroute -n 203.0.113.10
ip route get 10.90.0.5
ip route get 1.1.1.1

Herbegin dan die verbinding, want ’n kliënt wat sy tabel by herverbinding herbou, sal ’n roete wat jy met die hand getik het, weggooi. Met ’n kill switch in werking, kyk of die eindpunt toegelaat word, anders kan die tonnel nie ná ’n netwerkverandering terugkeer nie en lyk die simptoom soos ’n onderbreking. Stoor die uitsondering in die profiel of die unit-lêer eerder as in ’n shell-geskiedenis, sodat die herverbinding dit herskep in plaas daarvan om dit uit te wis.