Zergatik tunel osoko ibilbide batek mozten duen daraman zerbitzaria

Aktibatu tunel oso bat eta helmuga guztiak VPN interfazearenak dira orain, tunela amaitzen duen makina barne. Tunela daramaten kanpoko paketeak makina horri zuzenduta daude, beraz ibilbideak mendeko duen garraioa kontsumitzen du azkenean. Ibilbide zehatz bat gehiagok konpontzen du, eta arrazoia ulertzea merezi du. Arrazoi hori gabe, hurrengo berreraikitzeak akatsa berriro sartzen du.

Bere garraioa jaten duen ibilbidea

Enkapsulazioak pakete bakoitza bigarren goiburu batean biltzen du. Kanpokoa tokiko helbide fisikotik zerbitzariaren helbide publikora zuzentzen da, eta esteka fisikoa zeharkatu behar du edozein tunel egon baino lehen.

Orain utzi helbide publiko horren bilaketari tunela aukeratzen. Paketea bidaltzeko, makinak enkapsulatu behar du, eta horrek helbide berbererako ibilbidea eskatzen du, tunela itzultzen duena. Bezeroek bi eratara kudeatzen dute hau. Arretatsu batek uko egiten dio ibilbide lehenetsia instalatzeari eta errore bat jakinarazten du, eta gutxiago arretatsuak arrakasta jakinarazi eta gero ezer ez du mugitzen. Hutsegite isilak arratsalde bat kostatzen du.

Aurrizki luzeenaren bat-etortzeak erabakitzen du bilaketa edozein metrika kontsultatu aurretik, beraz helbide bakarreko ibilbide batek makinako ibilbide lehenetsi guztiak gainditzen ditu. Hori da konponketaren atzeko mekanismo osoa.

Instalatu salbuespena lehenetsia baino lehen

Sortu helbide bakarreko ibilbide bat zerbitzariarentzat, ate fisikoa hurrengo jauzi gisa, ibilbide lehenetsia mugitu baino lehen. Ordenak garrantzia du: geroago instalatzeak tunel hautsia duela bizitzea esan nahi du idazten duzun bitartean.

Bezero gehienek hau eskatu gabe egiten dute. OpenVPN urruneko helbidea bilatzen du eta finkatzen du ate lehenetsia berridatzi aurretik, eta bere route-delay aukera sekuentzia hori lehiatzen den plataformetarako dago. wg-quick-ek erabat beste bide bat hartzen du, paketeak markatuz eta politika-arau bat kontsultatuz salbuespen bat gehitu ordez. Mekanismo desberdinak, baldintza bera: kanpoko paketeak sortzen duen tunelatik ihes egin behar du.

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

Bilaketaren irteera onarpen-proba da. Gailu fisikoa eta hurrengo jauzi fisikoa izendatu behar ditu. Erantzun horretan tunel-gailu bat egoteak salbuespena falta dela esan nahi du, edo gainditzen duen zerbaiten ondoren jarri zela.

Ispilu-irudia zerbitzarian

Tranpa bera beste aldean itxoiten du, alderantziz. Eman zerbitzariari beste tunel baten bidezko ibilbide lehenetsi bat, edo bultzaiozu bere bezeroen helbide publikoak estaltzen dituen ibilbide bat, eta bere erantzunek norabide okerreko ohitura hartuko dute.

Imajinatu konektatzen eta eskaera bat bidaltzen duen bezero bat. Erantzuna bezero horren helbide publikora zuzentzen da, eta hori orain tunel-ibilbide batekin bat dator, beraz beste interfaze batetik irteten da bezeroak inoiz markatu ez zuen iturri bat daramala. Bezeroak pakete hori jaso eta hala ere bazter dezake, ezerk ez baitu bidali zuen eskaerarekin lotzen. Abiatu zerbitzariaren bideratze-erabakitzik, ez bezeroaren denbora-mugatik, horietako batek soilik erakusten baitu benetako hautua.

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

Hiru konponketa daude eta ez dira berdinak. Zerbitzua helbide fisikoari lotzea, edo iturria itzultzea, biek bideratze-erabakia ezkutatzen dute zuzendu beharrean. Tunel-putzuaren erantzun-trafikoa taula dedikatu batetik bidaltzeak kausa konpontzen du, eta beste biak onargarriak dira bideratze-diseinua izoztuta dagoen bitartean soilik.

Tunelak etengabe lapurtzen dituen salbuespenak

Eskukada bat zeregin Internet irekia behar dute tunelak ibilbide lehenetsia duen bitartean ere, eta bakoitzak bere salbuespena behar du. DNS dinamikoko eguneratzailea izaten da lehena hausten.

Hornitzailea ebazten du, konexio bat irekitzen du eta bere paketeak duela segundo batzuetan aldatu zen helbidea duen tunel batetik doazela aurkitzen du, beraz eguneratzeak huts egiten du edo helbide okerra argitaratzen du. Hiru irteera: finkatu hornitzailea ostalari-ibilbide batekin ate fisikoaren bidez, exekutatu eguneratzea tunela altxatu aurretik, edo eman eguneratzaileari tunelak inoiz ukitzen ez duen politika-taula bat. Denbora-sinkronizazioak esposizio bera du resolverrik gabe abiarazten den gailu batean, eta ziurtagiriak baliozkotzeko muturrek zerrendan dute lekua arrazoi beragatik.

Inork idatzi ez duen salbuespena hurrengo berreraikitzeak isilka botako duen salbuespena da.

Frogatu berriz konektatu ondoren, ez aurretik

Probatu hiru helmuga, ez bat: muturra, tunelaren atzeko helbide pribatu bat eta hortik haragoko helbide publiko bat. Bilaketa arrakastatsu bakar batek ia ezer ez du esaten beste bietaz.

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

Ondoren berrabiarazi konexioa, berriz konektatzean bere taula berreraikitzen duen bezero batek eskuz idatzitako ibilbidea baztertuko baitu. Kill switch bat martxan badago, egiaztatu muturra baimenduta dagoela, bestela tunelak ezingo du itzuli sare-aldaketa baten ondoren eta sintomak etena emango du. Gorde salbuespena profilean edo unit fitxategian shell historialean izan beharrean, berriz konektatzeak berriro sor dezan ezabatu beharrean.