Miksi täystunnelin reitti katkaisee sen kantavan palvelimen

Kytke täystunneli päälle, ja jokainen kohde kuuluu nyt VPN-rajapintaan, mukaan lukien kone, joka päättää sen. Tunnelia kantavat ulommat paketit on osoitettu sille koneelle, joten reitti kuluttaa lopulta sen liikenteen, josta se riippuu. Yksi ylimääräinen täsmällinen reitti ratkaisee sen, ja syy kannattaa ymmärtää. Ilman sitä syytä seuraava uudelleenrakennus tuo vian takaisin.

Reitti, joka syö oman kuljetuksensa

Kehystys käärii jokaisen paketin toiseen otsikkoon. Ulompi on osoitettu paikallisesta fyysisestä osoitteesta palvelimen julkiseen osoitteeseen, ja sen on ylitettävä fyysinen linkki ennen kuin mikään tunneli voi olla olemassa.

Anna nyt kyseisen julkisen osoitteen haun valita tunneli. Lähettääkseen paketin koneen on kehystettävä se, mikä vaatii reitin samaan osoitteeseen, joka palauttaa tunnelin. Asiakkaat hoitavat tämän yhdellä kahdesta tavasta. Huolellinen kieltäytyy asentamasta oletusreittiä ja raportoi virheen, kun taas vähemmän huolellinen raportoi onnistumisen ja ei sitten siirrä mitään. Hiljainen epäonnistuminen on se, joka maksaa yhden iltapäivän.

Pisimmän etuliitteen osuma ratkaisee haun ennen minkään metriikan katsomista, joten yhden osoitteen reitti päihittää koneen jokaisen oletusreitin. Se on koko korjauksen mekanismi.

Asenna poikkeus ennen oletusreittiä

Luo palvelimelle yhden osoitteen reitti, fyysinen yhdyskäytävä seuraavana hyppynä, ennen kuin oletusreitti liikkuu. Järjestyksellä on väliä: sen asentaminen jälkeenpäin tarkoittaa elämistä rikkinäisen tunnelin kanssa kirjoittaessasi.

Useimmat asiakkaat tekevät tämän pyytämättä. OpenVPN hakee etäosoitteen ja kiinnittää sen ennen oletusyhdyskäytävän uudelleenkirjoittamista, ja sen route-delay-vaihtoehto on olemassa alustoille, joilla tämä järjestys kilpailee. wg-quick ottaa täysin toisen tien, merkitsemällä paketteja ja kysymällä politiikkasääntöä sen sijaan, että lisäisi poikkeuksen. Erilaiset mekanismit, sama vaatimus: ulomman paketin on paettava tunnelista, jonka se luo.

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

Haun tulos on hyväksymistesti. Sen on nimettävä fyysinen laite ja fyysinen seuraava hyppy. Tunnelilaite siinä vastauksessa tarkoittaa, että poikkeus puuttuu tai se sijoitettiin jonkin sellaisen jälkeen, joka ohittaa sen.

Peilikuva palvelimella

Sama ansa odottaa toisella puolella, käännettynä. Anna palvelimelle oletusreitti toisen tunnelin kautta tai työnnä sille reitti, joka kattaa asiakkaiden julkiset osoitteet, niin sen vastaukset omaksuvat väärän suunnan tavan.

Kuvittele asiakas, joka yhdistää ja lähettää pyynnön. Vastaus on osoitettu kyseisen asiakkaan julkiseen osoitteeseen, joka vastaa nyt tunnelireittiä, joten se lähtee eri rajapinnasta kantaen lähdettä, jota asiakas ei koskaan valinnut. Asiakas voi vastaanottaa paketin ja silti hylätä sen, koska mikään ei sido sitä lähetettyyn pyyntöön. Lähde palvelimen reitityspäätöksestä äläkä asiakkaan aikakatkaisusta, sillä vain toinen niistä näyttää todellisen valinnan.

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

Korjauksia on kolme, eivätkä ne ole samanarvoisia. Palvelun kiinnittäminen fyysiseen osoitteeseen tai lähteen kääntäminen molemmat piilottavat reitityspäätöksen sen korjaamisen sijaan. Vastausliikenteen lähettäminen tunnelialtaalle erillisen taulun kautta korjaa syyn, ja kaksi muuta ovat hyväksyttäviä vain niin kauan kuin reitityssuunnittelu on jäädytetty.

Poikkeukset, joita tunneli yhä varastaa

Koura tehtäviä tarvitsee avoimen internetin, vaikka tunneli omistaa oletusreitin, ja jokainen tarvitsee oman poikkeuksensa. Dynaamisen DNS:n päivittäjä on yleensä ensimmäinen, joka hajoaa.

Se ratkaisee palveluntarjoajan, avaa yhteyden ja huomaa omien pakettiensa kulkevan tunnelin läpi, jonka osoite muuttui sekunteja sitten, joten päivitys epäonnistuu tai julkaisee väärän osoitteen. Kolme ulospääsyä: kiinnitä palveluntarjoaja isäntäreitillä fyysisen yhdyskäytävän kautta, aja päivitys ennen kuin tunneli nousee, tai anna päivittäjälle politiikkataulu, johon tunneli ei koskaan koske. Ajan synkronointi altistuu samalla tavalla laitteella, joka käynnistyy ilman ratkaisijaa, ja varmenteiden validointipäätepisteet kuuluvat listalle samasta syystä.

Poikkeus, jota kukaan ei kirjoittanut, on poikkeus, jonka seuraava uudelleenrakennus pudottaa hiljaa.

Todista se uudelleenyhdistämisen jälkeen, ei ennen

Testaa kolmea kohdetta, älä yhtä: päätepiste, yksityinen osoite tunnelin takana ja julkinen osoite sen ulkopuolella. Yksi onnistunut haku ei kerro kahdesta muusta juuri mitään.

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

Käynnistä sitten yhteys uudelleen, koska asiakas, joka rakentaa taulunsa uudelleen yhdistäessään, heittää pois käsin kirjoittamasi reitin. Jos kill switch on pelissä, tarkista, että päätepiste on sallittu, muuten tunneli ei voi palata verkkomuutoksen jälkeen ja oire näyttää katkokselta. Tallenna poikkeus profiiliin tai unit-tiedostoon äläkä shellin historiaan, jotta uudelleenyhdistäminen luo sen uudelleen sen sijaan, että pyyhkii sen.