Je li potpuno tuneliranje jednostavnije od dugog popisa podijeljenog tuneliranja?

Popis podijeljenog tuneliranja počinje s tri aplikacije i na kraju pokriva većinu računala, a svaki novi redak je nečiji izuzetak. U tom trenutku popis je tiho postao zadani izbor s dodatnim koracima. Potpuno tuneliranje okreće raspored: sve ulazi u tunel osim ako dokumentirano izuzeće ne kaže drukčije. Je li to jednostavnije, ovisi o gatewayu i o lokalnim servisima koje biste pokvarili.

Počnite brojanjem pravila koja održavate

Prebrojite unose, a zatim prebrojite koliko ih ima imenovanog vlasnika i datum zadnje provjere. Drugo je broj koji je važan, jer izuzeće bez vlasnika ne može se procijeniti kada se softver na koji se odnosi preimenuje ili zamijeni. Pravila vezana uz putanju izvršne datoteke tiho zataje nakon ažuriranja, a kvar izgleda kao nestabilan VPN, a ne kao zastarjelo pravilo. Zapišite popis prije nego što o njemu stvorite mišljenje.

Svaki unos trebao bi odgovoriti na tri pitanja: što se kvari bez njega, tko je to odlučio i kako biste primijetili da je razlog istekao. Unosi koji ne mogu odgovoriti na sva tri kandidati su za brisanje, a ne za migraciju, a njihovo brisanje najprije čini kasniju usporedbu iskrenom.

Ako većina unosa usmjerava velik dio prometa, već vodite potpuni tunel s priloženim teretom održavanja. Odluka je tada o tome gdje zadani izbor stanuje, a ne o tome treba li ga imati.

Provjerite može li gateway nositi zadani izbor

Potpuno tuneliranje premješta svaki paket na jedan uređaj, što istodobno mijenja opterećenje CPU-a, conntrack tablicu, prevođenje adresa i potrebu za izlaznom propusnošću tog uređaja. Gateway koji je udobno služio nekoliko internih podmreža možda nije bio dimenzioniran za sve pregledavanje jednog korisnika. Gledajte na najveći očekivani broj istovremenih sesija, a ne na prosjek, jer se vrh prvi kvari.

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

Izmjerite isto opterećenje prije i nakon promjene umjesto da zaključujete iz specifikacija. Jedno poslijepodne uobičajene upotrebe na jednom računalu pokazat će je li gateway blizu granice, i to ne košta ništa u usporedbi s otkrivanjem u ponedjeljak ujutro.

Provjerite i path MTU od kraja do kraja, jer potpuni zadani izbor izlaže svaku aplikaciju najvećoj veličini paketa tunela. Aplikacije koje su radile izvan tunela sada mogu ovisiti o ponašanju fragmentacije o kojem nikad niste morali razmišljati.

Potvrdite da lokalni servisi i privatni DNS još rade

Popišite što mora ostati lokalno prema protokolu, a ne prema nazivu aplikacije: protokoli za otkrivanje pisača i zaslona, bridge za pametni dom, administracijska stranica usmjerivača, lokalni razvojni poslužitelj dostupan pod imenom koje se razrješava samo na LAN-u. To se kvari kada zadana ruta počne pokazivati u tunel, i kvari se tiho jer ništa ne bilježi grešku na klijentu.

Privatni DNS je druga ovisnost. Ako je interna imena prije razrješavao resolver tunela, ništa se ne mijenja; ako su se razrješavala lokalno, potpuni zadani izbor mora ih dovesti do resolvera koji poznaje zone. Testirajte jedno interno i jedno javno ime nakon promjene umjesto da pretpostavite da je popis resolvera preživio.

Zapišite lokalna izuzeća u profil koji ih posjeduje. Izuzeće koje postoji samo u nečijem pamćenju prvo je što sljedeća migracija izgubi.

Migrirajte jedan profil i provjerite granice

Promijenite profil kroz njegovu vlastitu konfiguraciju, umjesto da naslažete novi zadani izbor na ručne rute koje su ostavili prijašnji eksperimenti. Te preostale rute uobičajen su uzrok migracije koja izgleda da radi i dan kasnije se ponaša nedosljedno. Držite stari profil dostupnim kako bi povratak bio izbor, a ne ponovna izgradnja.

Zatim provjerite dvije granice odvojeno: da javna i privatna odredišta rade, i da neželjeni promet ne izlazi izvan tunela. Uspješno učitavanje stranice dokazuje prvo i ne govori ništa o drugom.

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

Ponovite provjeru nakon ponovnog spajanja i nakon prekida, jer je kill switch koji blokira promet tijekom pada drugo svojstvo od rute koja se poslije ispravno obnovi. Jednostavniji je onaj dizajn čiju stvarnu pokrivenost još možete objasniti nakon što se aplikacija ili mreža promijeni.