Twee VPN-hops op een Pi: watter roete dra watter eweknie

Twee tonneladresse op een klein bord lyk soos 'n fout, en die refleks is om een te skrap. Daardie refleks breek die ding wat dit veronderstel was om op te ruim. 'n Gasheer wat twee hops dra, hou een adres per aanhegting, en elke adres word deur 'n ander roete gekies. Die vraag wat werd is om te vra, is watter roete watter draer vir watter bestemming kies, nie hoeveel adresse daar bestaan nie.

Drie bestemmings wat verskillende draers nodig het

'n Tweestap-ketting is drie bestemmingsklasse wat op mekaar gestapel is, en elkeen word deur 'n ander aanhegting gedra. Die buitenste eweknie moet oor die fisiese skakel bereik word. Die binneste eweknie moet deur die buitenste tonnel bereik word. Die gedekte toepassing se bestemming moet deur die binneste tonnel bereik word, en dié se eie vervoer word deur die buitenste een gedra.

Vul die rye in met die leser se werklike adresse voordat jy aan 'n roete raak, want die tabel is eers nuttig wanneer dit konkreet is. 'n Werkende ketting bevredig al vier rye op dieselfde tyd, en 'n halfwerkende ketting bevredig gewoonlik een van hulle met die verkeerde draer. Om die verkeerde ry as die fout te lees, is wat 'n roeteringsprobleem in 'n middag se wysigings verander.

Adresse het rolle, nie 'n telling nie

Linux laat verskeie adresse op een koppelvlak en verskeie tonnels op een gasheer toe, so 'n telling sê niks oor korrektheid nie. Wat saak maak, is watter adres aan watter aanhegting behoort, en of die roete vir 'n gegewe eweknie die aanhegting kies wat jy bedoel het. Drie aansigte antwoord dit uit drie rigtings, en dit is die moeite werd om dit elke keer in dieselfde volgorde te lees.

Die adres-inventaris wys wat bestaan en watter aanhegting dit besit. Die roetetabel beantwoord die draervraag vir gewone bestemmingsverkeer. Die beleidsaansig beantwoord dit weer vir verkeer wat deur bron of merk gekies word, wat die normale reëling is wanneer twee kliënte een gasheer deel.

ip -4 addr show
ip -4 route show table all
ip rule show

Om 'n adres te skrap omdat die lys lank lyk, kan deel van die pad verwyder, en om 'n roete te skrap omdat dit oorbodig lyk, doen dieselfde ding stiller. Nie een lewer 'n fout nie; die eweknie hou net op om op die pad te antwoord wat jy bedoel het, terwyl dit deur 'n ander bereikbaar bly. 'n Toepassing wat die binneste eweknie se uitgangadres rapporteer, bewys nie dat die verkeer die buitenste tonnel gekruis het nie, want direkte toegang lewer dieselfde waarneming. Daardie gaping tussen 'n waarneming en 'n bewys is waarom die draer by die roeteringslaag nagegaan word.

Aktiveringsorde klop 'n vaste slaap

As die binneste kliënt afhanklik is van 'n adres of 'n roete wat die buitenste kliënt verskaf, moet aktivering op daardie hulpbron wag eerder as op 'n vertraging. 'n Slaap werk tot die dag wanneer die buitenste tonnel stadig is, en dan misluk dit af en toe op 'n manier wat niemand kan herhaal nie. Afhanklikheidgebaseerde ordening verwyder die raaiskoot en kos niks behalwe om die afhanklikheid een keer te beskryf. Koppelvlakname is ook nie 'n ordeningsmeganisme nie.

Die kern deel name soos tun0 en tun1 in skeppingsorde uit, en daardie orde kan oor herstarte of herverbindings verander. Bind konfigurasie aan 'n identiteit wat die gereedskap verskaf, of aan 'n naam wat jy doelbewus toeken. 'n Naam wat jy kies, is 'n kontrak; 'n naam wat die kern kies, is 'n ongeluk.

Hou elke kliënt se vervoer uit die ander se toepassingsroete, en wees presies oor wat die OpenVPN 2.6-roeteringsopsies werklik belowe. Die gedokumenteerde standaard-herleidingsmeganisme hou 'n kliënt in staat om sy eie afgeleë eweknie deur die poort te bereik wat reeds bestaan het, wat een spesifieke rekursielus afsny. Dit verander nie een kliënt in 'n ander kliënt se draer nie, so die res van die ketting bly jou ontwerp. Waar die ketting 'n beleid eerder as 'n roete nodig het, skryf 'n eksplisiete bron- of merkreeël en toets dit met die verkeer wat dit veronderstel is om te pas.

Wat gebeur wanneer die buitenste hop sterf

Voordat die ketting as volledig geld, besluit wat gebeur wanneer die buitenste hop verdwyn. Die binneste kliënt se vervoer sterf saam daarmee, en die volgende stap is 'n beleidsvraag eerder as 'n tegniese een: misluk, probeer weer, of verbind direk oor die fisiese skakel. Daardie derde uitkoms is die een om oor te dink. Dit verander stilweg 'n tweehop-ontwerp in 'n eenhop-ontwerp op die oomblik wanneer die gebruiker glo dat dekking nog ongeskonde is.

As twee hops verpligtend is, moet die binneste kliënt nie 'n direkte pad kan vestig wanneer die buitenste een weg is nie, en die manier om dit te weet is om die buitenste hop te breek en te kyk wat die binneste een doen. 'n Goedgekeurde terugval is 'n wettige antwoord, maar dit moet neergeskryf, getoets en gekommunikeer word. 'n Terugval wat niemand gedokumenteer het nie, is tydens 'n voorvalondersoek nie van 'n lek te onderskei nie.

DNS en die ander adresfamilie hoort by dieselfde besluit. 'n Plaaslik gegenereerde opsoek volg die gasheer se eie beleid eerder as dié van 'n deurgevoerde kliënt, so die oplosser wat vir deurgevoerde verkeer werk, is dalk nie die een wat die gasheer self gebruik nie.

Aanvaar elke laag in die orde waarin jy dit gebou het

Toets in die orde waarin die ketting gebou is: die buitenste tonnel alleen, dan die binneste kliënt se vervoer deur die buitenste tonnel, dan die toepassing deur die binneste tonnel. Elke aanvaarding moet 'n vars verbinding wees eerder as 'n bladsy wat reeds oop was. Breek en herstel dan elke laag afsonderlik en kyk wat die volgende een doen.

Die terugvalresultaat is die waardevolste waarneming hier, en die een wat 'n openbare-IP-bladsy nooit wys nie. Stoor die ewekniepaaie, die adresse wat hulle gebruik en daardie uitkoms langs die konfigurasie, want die gelukkige pad is nie die deel wat later bevraagteken word nie.