Vastaus lähtee LAN-verkkoon, ei tunneliin: miksi ja miten

Yhdyskäytävän kautta julkaistu palvelu toimii suurimmasta osasta internetiä ja epäonnistuu yhdestä toimistosta. Joku tutkii tunnelia, näkee pyynnön saapuvan ja päättelee, että vastauksen on kuljettava sama reitti takaisin. Linux ei toimi niin, eikä mikään tunnelin tutkiminen muuta vastausta. Vastaus reititetään kohteen mukaan, ja tämä yksi epäonnistuva kutsuja istuu aliverkossa, johon isäntä yltää jo suoraan.

Mikä oikeastaan ratkaisee lähtevän paketin

Ydin hakee reitin paketin kohteelle, tarkistaa käytäntösäännöt prioriteettijärjestyksessä ja sitten taulun, jonka vastaava sääntö valitsee. Rajapinnalla, jolta paketti saapui, ei ole osaa, ellei sääntöä tai merkintää ole kirjoitettu tekemään siitä merkityksellistä. Tämä on tämän isännän reititystosiasia, ei tunnelin vika.

Tunnelista vastaanotettu pyyntö voi siis tuottaa vastauksen, joka lähtee fyysisen rajapinnan kautta, ja virtauksesta tulee yksisuuntainen ilman, että mikään laite ilmoittaa virheestä. Tarkista molemmat suunnat ennen kuin teet johtopäätöksen tunnelista. Väärään suuntaan lähtevä vastaus katoaa tunnelin laskureista, minkä vuoksi kaksi päätä ovat eri mieltä siitä, lähetettiinkö mitään. Huomaa, mikä laskuri liikkui, ennen kuin kosket sääntöön.

Miksi paikallinen aliverkko voittaa

Isännällä, jolla on osoite paikallisessa verkossa, on yhdistetty reitti tälle etuliitteelle päätaulussa, ja yhdistetty reitti on suora osuma. Kun kutsuja tulee samasta aliverkosta, haku löytää paikallisen linkin ennen kuin tunnelia edes harkitaan.

Juuri epäsymmetria tekee diagnosoinnista sekavaa. Laajemman internetin kutsujat toimivat, koska ne eivät vastaa mitään paikallista reittiä, kun taas ainoa kutsuja, joka jakaa toimiston etuliitteen, epäonnistuu, ja juuri sillä kutsujalla joku testaa.

Peereiden kattavuus ei ole sama kuin asennetut reitit

Tunnelin puolella peerin sallitut alueet kuvaavat, mitä tunneliin saa lähettää ja mitkä lähteet hyväksytään siitä. Ne eivät kerro mitään siitä, mihin paikallinen reititystaulu lähettää paketin.

Jos tunnelityökalu asentaa isännälle oletusreitin, se voi vetää asiaankuulumatonta liikennettä tunneliin sivuvahinkona. Siellä, missä päätöksen pitäisi kuulua käytäntösäännölle, työkalun reittien asennusvaihtoehto on juuri sen estämiseksi, ja osoitteet, avaimet ja päätepisteen asetukset pysyvät täsmälleen sellaisina kuin ne olivat. Mukavuuden vuoksi lisätty oletusreitti on tavallinen tapa, jolla isäntä menettää oman paikallisen verkkonsa.

Valitse taulu lähdeosoitteen mukaan

Lähteeseen perustuva sääntö lähettää palvelun osoitteesta tulevat vastaukset yksityiseen tauluun, jonka oletus on tunneli, kun taas kaikki muu käyttää edelleen päätaulua. Valitse taulu- ja prioriteettinumerot, joita ei käytetä paikallisesti, ja lue olemassa olevat säännöt ennen kuin lisäät mitään. Lue elävät säännöt tallennetun tiedoston sijaan, sillä ne voivat erota uudelleenkäynnistyksen jälkeen.

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

Viimeinen rivi saa puuttuvan reitin epäonnistumaan näkyvästi sen sijaan, että se putoaisi takaisin paikalliselle linkille. Lähteen on oltava todella isännälle osoitettu, ja tavallisten paikallisten ja päähaun on pysyttävä aiemmilla paikoillaan. Sääntö valitsee taulun lähteen mukaan; se ei vertaa etuliitteiden pituuksia taulujen välillä.

Vahvista polku ja sitten palvelu

Kysy ytimeltä, mitä se tekisi sen sijaan, että päättelet kaappauksesta, käyttämällä palvelun osoitetta lähteen valitsimena. Väärä vastaus tässä säästää kokonaisen pakettijäljityksen.

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

Tulosteen pitäisi nimetä tunneli. Testaa sitten lähdettä, johon et koskenut, ja varmista, että se ottaa edelleen paikallisen linkin, jotta muutos pysyi yhden osoitteen sisällä. Laajempi valitsin ei todistaisi mitään alkuperäisestä valituksesta.

Mitä tämä ei korjaa

Jätä edelleenlähetys, palomuurisäännöt ja ICMPv6-käyttäytyminen yhdyskäytävällä sellaisiksi kuin ne olivat, sillä lähdereitti ei korvaa mitään niistä. Puuttuva Packet Too Big -viesti rikkoo edelleen suuria vastauksia riippumatta siitä, mikä taulu voitti haun. Korjaa se ennen reitityssääntöjen lisäämistä, muuten oire jää muutoksen jälkeen.

Vahvista julkaisumalli ennen kuin sovellat mitään tästä. Käänteinen välityspalvelin, joka avaa oman taustayhteytensä, esittää oman lähteensä eikä säilytä kutsujaa, joten tämä vika ei voi esiintyä siinä mallissa. Säännön soveltaminen siellä lisäisi reitityspoikkeuksen, joka ei ratkaise mitään ja piilottaa todellisen syyn.

Kirjoita lopuksi sääntönumerot ja taulu isännän konfiguraationhallintaan. Käsin lisätty käytäntösääntö katoaa seuraavassa uudelleenrakennuksessa, ja toimiston kutsuja palaa saman valituksen kanssa.