Die antwoord verlaat die LAN, nie die tonnel nie: hoekom en hoe

’n Diens wat deur ’n gateway gepubliseer word, werk vanaf die grootste deel van die internet en faal by een kantoor. Iemand ondersoek die tonnel, sien die versoek aankom en maak die gevolgtrekking dat die antwoord dieselfde pad terug volg. Linux werk nie so nie, en geen mate van ondersoek aan die tonnel sal die antwoord verander nie. Die antwoord word volgens bestemming gerouteer, en daardie een falende oproeper sit op ’n subnet wat die gasheer reeds direk bereik.

Wat werklik oor ’n uitgaande pakket besluit

Die kernel soek ’n roete op vir die pakket se bestemming, en raadpleeg beleidsreëls in prioriteitsorde en daarna die tabel wat ’n ooreenstemmende reël kies. Die koppelvlak waarop ’n pakket aangekom het, speel geen rol nie, tensy ’n reël of ’n merkie geskryf is om dit saak te maak. Dit is ’n roetefeit oor hierdie gasheer, nie ’n fout in die tonnel nie.

’n Versoek wat op die tonnel ontvang word, kan dus ’n antwoord lewer wat deur die fisiese koppelvlak uitgaan, en die vloei word eenrigting sonder dat enige toestel ’n fout rapporteer. Kontroleer beide rigtings voordat jy ’n gevolgtrekking oor die tonnel maak. ’n Antwoord wat die verkeerde kant uitgaan, verdwyn uit die tonneltellers, en daarom verskil die twee kante oor of iets gestuur is. Let op watter teller beweeg het voordat jy aan ’n reël raak.

Waarom die plaaslike subnet wen

’n Gasheer met ’n adres op ’n plaaslike netwerk het ’n gekoppelde roete vir daardie voorvoegsel in die hooftabel, en ’n gekoppelde roete is ’n direkte passing. Wanneer die oproeper uit dieselfde subnet kom, vind die opsoek die plaaslike skakel voordat die tonnel ooit oorweeg word.

Dit is die asimmetrie wat dit verwarrend maak om te diagnoseer. Oproepers van die wyer internet werk omdat hulle geen plaaslike roete pas nie, terwyl die een oproeper wat die kantoorvoorvoegsel deel, faal, en dit is juis die oproeper waarmee iemand toets.

Portuurdekking is nie dieselfde as geïnstalleerde roetes nie

Aan die tonnelkant beskryf ’n portuur se toegelate reekse wat in die tonnel gestuur mag word en watter bronne daaruit aanvaar word. Hulle sê niks oor waarheen die plaaslike roetetabel ’n pakket sal stuur nie.

As die tonnelgereedskap ’n verstekroete op die gasheer installeer, kan dit onverwante verkeer as kollaterale skade in die tonnel intrek. Waar ’n beleidsreël eerder die besluit behoort te neem, bestaan die gereedskap se roete-installasie-opsie juis om dit te verhoed, en die adresse, sleutels en eindpuntinstellings bly presies soos hulle was. ’n Verstekroete wat vir gerief bygevoeg is, is ’n algemene manier waarop ’n gasheer sy eie plaaslike netwerk verloor.

Kies die tabel volgens die bronadres

’n Reël op grond van die bron stuur antwoorde vanaf die diensadres na ’n private tabel waarvan die verstek die tonnel is, terwyl alles anders die hooftabel bly gebruik. Kies tabel- en prioriteitsnommers wat plaaslik ongebruik is, en lees die bestaande reëls voordat jy iets invoeg. Lees die lewendige reëls eerder as ’n gestoorde lêer, want die twee kan ná ’n herbegin verskil.

ip -6 route add default dev wg0 table 200
ip -6 rule add priority 32000 from 2001:db8:aa::20/128 lookup 200
ip -6 rule add priority 32001 from 2001:db8:aa::20/128 unreachable

Die laaste reël laat ’n ontbrekende roete sigbaar misluk eerder as om na die plaaslike skakel terug te val. Die bron moet werklik aan die gasheer toegewys wees, en die gewone plaaslike en hoof-opsoeke moet in hul vroeër posisies bly. Die reël kies ’n tabel volgens bron; dit vergelyk nie voorvoegsellengtes tussen tabelle nie.

Bevestig die pad, dan die diens

Vra die kernel wat dit sou doen in plaas daarvan om uit ’n opname af te lei, met die diensadres as bronkieser. ’n Verkeerde antwoord hier spaar ’n hele pakketspoor.

ip -6 route get 2001:db8:bb::30 from 2001:db8:aa::20

Die uitset behoort die tonnel te noem. Toets dan ’n bron waaraan jy nie geraak het nie en bevestig dat dit steeds die plaaslike skakel gebruik, sodat die verandering tot een adres beperk gebly het. ’n Wyere kieser sou niks oor die oorspronklike klag bewys nie.

Wat dit nie regstel nie

Hou aanstuur, firewall-reëls en ICMPv6-gedrag op die gateway soos dit was, want ’n bronroete vervang nie een daarvan nie. ’n Ontbrekende Packet Too Big-boodskap breek steeds groot antwoorde, maak nie saak watter tabel die opsoek gewen het nie. Stel dit reg voordat jy roetereëls byvoeg, anders oorleef die simptoom die verandering.

Bevestig die publikasiemodel voordat jy enigiets hiervan toepas. ’n Omgekeerde proxy wat sy eie backend-verbinding oopmaak, wys sy eie bron en bewaar nie die oproeper nie, so hierdie fout kan nie in daardie ontwerp voorkom nie. Om die reël daar toe te pas, sou ’n roete-uitsondering byvoeg wat niks oplos nie en die werklike oorsaak verberg.

Skryf laastens die reëlnommers en die tabel in die gasheer se konfigurasiebestuur in. ’n Beleidsreël wat met die hand bygevoeg is, verdwyn by die volgende herbou, en die kantooroproeper kom terug met dieselfde klag.