A válasz a LAN felé távozik, nem az alagúton: miért és hogyan

Egy átjárón keresztül közzétett szolgáltatás az internet nagy részéből működik, és egy irodából meghiúsul. Valaki megvizsgálja az alagutat, látja megérkezni a kérést, és arra a következtetésre jut, hogy a válasznak ugyanazon az úton kell visszamennie. A Linux nem így működik, és az alagút semmilyen vizsgálata nem változtatja meg a választ. A válasz a cél szerint van irányítva, és az az egyetlen meghiúsuló hívó olyan alhálózaton van, amelyet a gazdagép már közvetlenül elér.

Mi dönt valójában egy kimenő csomagról

A kernel útvonalat keres a csomag céljához, prioritási sorrendben megvizsgálja a házirend-szabályokat, majd azt a táblát, amelyet egy egyező szabály kiválaszt. A csomag érkezési interfésze semmilyen szerepet nem játszik, hacsak nem írtak szabályt vagy jelölést, hogy számítson. Ez ennek a gazdagépnek az útválasztási ténye, nem az alagút hibája.

Az alagúton fogadott kérés tehát olyan választ eredményezhet, amely a fizikai interfészen távozik, és a folyam egyirányúvá válik anélkül, hogy bármely eszköz hibát jelentene. Mindkét irányt ellenőrizze, mielőtt következtetést vonna le az alagútról. A rossz irányba távozó válasz eltűnik az alagút számlálóiból, ezért a két vég nem ért egyet abban, hogy történt-e egyáltalán küldés. Figyelje meg, melyik számláló mozdult el, mielőtt bármelyik szabályhoz nyúlna.

Miért nyer a helyi alhálózat

Az a gazdagép, amelynek helyi hálózaton van címe, összekapcsolt útvonalat tart a fő táblában ehhez az előtaghoz, az összekapcsolt útvonal pedig közvetlen egyezés. Amikor a hívó ugyanabból az alhálózatból érkezik, a keresés a helyi kapcsolatot találja meg, mielőtt az alagutat egyáltalán figyelembe vennék.

Éppen az aszimmetria teszi zavaróvá a diagnózist. A szélesebb internetről érkező hívók működnek, mert nem egyeznek egyetlen helyi útvonallal sem, miközben az egyetlen hívó, aki az iroda előtagját megosztja, meghiúsul, és pontosan ezzel a hívóval szokott valaki tesztelni.

A peer-lefedettség nem ugyanaz, mint a telepített útvonalak

Az alagút oldalán egy peer engedélyezett tartományai leírják, mi küldhető az alagútba, és milyen források fogadhatók el belőle. Semmit nem mondanak arról, hová küldi a helyi útválasztási tábla a csomagot.

Ha az alagút eszköze alapértelmezett útvonalat telepít a gazdagépre, azzal mellékes kárként nem összefüggő forgalmat ránthat az alagútba. Ahol helyette egy házirend-szabályé kellene legyen a döntés, ott az eszköz útvonaltelepítési lehetősége éppen ennek megakadályozására létezik, és a címek, kulcsok és végpont-beállítások pontosan úgy maradnak, ahogy voltak. A kényelemből hozzáadott alapértelmezett útvonal gyakori módja annak, hogy egy gazdagép elveszítse a saját helyi hálózatát.

A forrás címe szerint válassza ki a táblát

A forrásalapú szabály a szolgáltatás címéről érkező válaszokat egy magán táblába küldi, amelynek alapértelmezése az alagút, miközben minden más továbbra is a fő táblát használja. Olyan tábla- és prioritásszámokat válasszon, amelyeket helyben nem használnak, és olvassa el a meglévő szabályokat, mielőtt bármit beszúr. Az élő szabályokat olvassa, ne egy mentett fájlt, mert a kettő újraindítás után eltérhet.

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

Az utolsó sor láthatóvá teszi a hiányzó útvonal meghiúsulását ahelyett, hogy visszaesne a helyi kapcsolatra. A forrásnak valóban a gazdagéphez kell rendelve lennie, és a szokásos helyi és fő kereséseknek a korábbi helyükön kell maradniuk. A szabály forrás szerint választ táblát; nem hasonlítja össze az előtagok hosszát a táblák között.

Erősítse meg az útvonalat, aztán a szolgáltatást

Kérdezze meg a kernelt, mit tenne, ahelyett hogy egy rögzítésből következtetne, a szolgáltatás címét használva forrásválasztóként. Egy rossz válasz itt egy egész csomagkövetést takarít meg.

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

A kimenetnek meg kell neveznie az alagutat. Ezután teszteljen egy forrást, amelyhez nem nyúlt, és erősítse meg, hogy az még mindig a helyi kapcsolatot használja, így a változás egyetlen címre korlátozódott. Egy szélesebb választó semmit nem bizonyítana az eredeti panaszról.

Mit nem javít ez meg

Hagyja a továbbítást, a tűzfal-szabályokat és az ICMPv6 viselkedését az átjárón úgy, ahogy voltak, mert a forrásútvonal egyiket sem helyettesíti. A hiányzó Packet Too Big üzenet továbbra is elrontja a nagy válaszokat, bármelyik tábla nyert is a keresésben. Javítsa meg ezt, mielőtt útválasztási szabályokat ad hozzá, különben a tünet túléli a változtatást.

Erősítse meg a közzétételi modellt, mielőtt bármit alkalmazna ebből. Az a fordított proxy, amely saját háttérkapcsolatot nyit, a saját forrását mutatja, és nem őrzi meg a hívót, ezért ez a hiba abban a kialakításban nem fordulhat elő. A szabály ott történő alkalmazása olyan útválasztási kivételt adna hozzá, amely semmit nem old meg, és elrejti a valódi okot.

Végül írja be a szabályszámokat és a táblát a gazdagép konfigurációkezelésébe. A kézzel hozzáadott házirend-szabály eltűnik a következő újraépítéskor, és az irodai hívó ugyanazzal a panasszal tér vissza.