Onko täydellinen tunnelointi yksinkertaisempaa kuin pitkä jaetun tunnelin lista?

Jaetun tunnelin lista alkaa kolmesta sovelluksesta ja päätyy kattamaan suurimman osan koneesta, ja jokainen uusi rivi on jonkun poikkeus. Siinä vaiheessa listasta on hiljaa tullut oletusarvo, jossa on ylimääräisiä vaiheita. Täydellinen tunnelointi kääntää järjestelyn toisinpäin: kaikki menee tunneliin, ellei dokumentoitu poikkeus sano muuta. Onko se yksinkertaisempaa, riippuu yhdyskäytävästä ja niistä paikallisista palveluista, jotka rikkoisit.

Aloita laskemalla ne säännöt, joita ylläpidät

Laske merkinnät ja laske sitten, kuinka monella on nimetty omistaja ja päivämäärä viimeisestä varmistuksesta. Toinen luku on se, jolla on merkitystä, koska poikkeusta, jota kukaan ei omista, ei voi arvioida, kun ohjelmisto, johon se viittaa, nimetään uudelleen tai korvataan. Suoritettavan tiedoston polkuun sidotut säännöt lakkaavat toimimasta hiljaa päivityksen jälkeen, ja vika näyttää epävakaalta VPN:ltä eikä vanhentuneelta säännöltä. Kirjoita lista muistiin ennen kuin muodostat siitä mielipiteen.

Jokaisen merkinnän pitäisi vastata kolmeen kysymykseen: mitä ilman sitä hajoaa, kuka sen päätti ja miten huomaisit, että syy on vanhentunut. Merkinnät, jotka eivät pysty vastaamaan kaikkiin kolmeen, ovat poistamisen ehdokkaita, eivät migraation, ja niiden poistaminen ensin tekee myöhemmästä vertailusta rehellisen.

Jos useimmat merkinnät reitittävät suuren osan liikenteestä, ajat jo täydellistä tunnelia, johon on liitetty ylläpitotaakka. Päätös koskee silloin sitä, missä oletusarvo asuu, ei sitä, pitäisikö sellainen olla.

Tarkista, jaksaako yhdyskäytävä kantaa oletusarvon

Täydellinen tunnelointi siirtää jokaisen paketin yhteen laitteeseen, mikä muuttaa samanaikaisesti sen laitteen prosessorikuormaa, conntrack-taulua, osoitteenmuunnosta ja lähtevän kaistan tarvetta. Yhdyskäytävä, joka palveli mukavasti muutamaa sisäistä aliverkkoa, ei ehkä ole mitoitettu käyttäjän koko selailulle. Katso suurinta odotettua samanaikaisten istuntojen määrää äläkä keskiarvoa, koska huippu hajoaa ensin.

ip -s link show dev tun0
conntrack -C
ss -s

Mittaa sama kuorma ennen muutosta ja sen jälkeen sen sijaan, että päättelet spesifikaatioista. Yksi tavallinen iltapäivä yhdellä koneella näyttää, onko yhdyskäytävä lähellä rajaa, eikä se maksa mitään verrattuna sen löytämiseen maanantaiaamuna.

Tarkista myös polun MTU päästä päähän, koska täysi oletusarvo altistaa jokaisen sovelluksen tunnelin suurimmalle pakettikoolle. Sovellukset, jotka toimivat tunnelin ulkopuolella, voivat nyt riippua pirstoutumiskäyttäytymisestä, jota sinun ei koskaan tarvinnut ajatella.

Varmista, että paikalliset palvelut ja yksityinen DNS toimivat edelleen

Luettele, mikä on jätettävä paikalliseksi protokollan eikä sovelluksen nimen mukaan: löytöprotokollat tulostimille ja näytöille, älykodin silta, reitittimen hallintasivu, paikallinen kehityspalvelin, johon päästään nimellä, joka ratkeaa vain lähiverkossa. Ne hajoavat, kun oletusreitti alkaa osoittaa tunneliin, ja ne hajoavat hiljaa, koska mikään ei kirjaa virhettä asiakkaassa.

Yksityinen DNS on toinen riippuvuus. Jos sisäiset nimet ratkaistiin aiemmin tunnelin ratkaisijan kautta, mikään ei muutu; jos ne ratkaistiin paikallisesti, täyden oletusarvon on vietävä ne ratkaisijalle, joka tuntee vyöhykkeet. Testaa muutoksen jälkeen yksi sisäinen ja yksi julkinen nimi sen sijaan, että olettaisit ratkaisijaluettelon säilyneen.

Kirjoita paikalliset poikkeukset profiiliin, joka omistaa ne. Vain jonkun muistissa pidettävä poikkeus on ensimmäinen asia, jonka seuraava migraatio menettää.

Migroi yksi profiili ja varmista rajat

Muuta profiilia sen omalla kokoonpanolla sen sijaan, että kerrostaisit uuden oletusarvon aiempien kokeiden jättämien manuaalisten reittien päälle. Ne jääneet reitit ovat tavallinen syy migraatioon, joka näyttää toimivan ja käyttäytyy epäjohdonmukaisesti päivää myöhemmin. Pidä vanha profiili saatavilla, jotta palautus on valinta eikä uudelleenrakennus.

Varmista sitten kaksi rajaa erikseen: että julkiset ja yksityiset kohteet molemmat toimivat, ja että ei-toivottu liikenne ei poistu tunnelin ulkopuolelle. Onnistunut sivun lataus todistaa ensimmäisen eikä kerro toisesta mitään.

ip route get 203.0.113.10
ip route get 10.40.8.15
resolvectl query intranet.example
curl -sS -o /dev/null -w "%{remote_ip}\n" https://example.com

Toista tarkistus uudelleenyhdistämisen jälkeen ja katkoksen jälkeen, koska katkoksen aikana liikennettä estävä kill switch on eri ominaisuus kuin reitti, joka palautuu sen jälkeen oikein. Yksinkertaisempi suunnittelu on se, jonka todellisen kattavuuden voit yhä selittää, kun sovellus tai verkko muuttuu.