Is volle tonneling eenvoudiger as ’n lang split-tonnelys?

’n Split-tonnelys begin met drie toepassings en dek uiteindelik die grootste deel van die masjien, en elke nuwe reël is iemand se uitsondering. Op daardie punt het die lys stilweg ’n verstek met ekstra stappe geword. Volle tonneling keer die reëling om: alles gaan in die tonnel in, tensy ’n gedokumenteerde uitsluiting anders sê. Of dit eenvoudiger is, hang af van die poort en van die plaaslike dienste wat jy sou breek.

Begin deur die reëls te tel wat jy onderhou

Tel die inskrywings en tel dan hoeveel daarvan ’n benoemde eienaar het en ’n datum waarop dit laas geverifieer is. Die tweede getal is die een wat saak maak, want ’n uitsondering wat niemand besit nie, kan nie beoordeel word wanneer die sagteware waarna dit verwys, hernoem of vervang word nie. Reëls wat aan ’n uitvoerbare pad gekoppel is, misluk stilweg ná ’n opdatering, en die mislukking lyk soos ’n VPN wat wankelrig is eerder as ’n verouderde reël. Skryf die lys neer voordat jy ’n mening daaroor het.

Elke inskrywing moet drie vrae beantwoord: wat breek sonder dit, wie het daaroor besluit, en hoe sou jy agterkom as die rede verval het. Inskrywings wat nie al drie kan beantwoord nie, is kandidate vir skrapping eerder as migrasie, en om hulle eerste te skrap maak die latere vergelyking eerlik.

As die meeste inskrywings ’n groot deel van die verkeer aanstuur, hardloop jy reeds ’n volle tonnel met ’n instandhoudingslas daarby. Die besluit gaan dan oor waar die verstek woon, nie oor of daar een moet wees nie.

Kyk of die poort die verstek kan dra

Volle tonneling stuur elke pakkie na een toestel, wat daardie toestel se CPU-las, conntrack-tabel, adresomsetting en opstroom-bandwydtevereiste gelyktydig verander. ’n Poort wat ’n paar interne subnetwerke gemaklik bedien het, is dalk nie geskaal vir al ’n gebruiker se blaaiery nie. Kyk na die grootste gelyktydige sessietelling wat jy verwag eerder as na die gemiddelde, want die piek is wat eerste breek.

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

Meet dieselfde werklading voor en ná die verandering eerder as om uit spesifikasies te redeneer. ’n Enkele middag gewone gebruik op een masjien sal wys of die poort naby ’n limiet is, en dit kos niks in vergelyking met om dit op ’n Maandagoggend te ontdek.

Kontroleer ook die pad-MTU van punt tot punt, want ’n volle verstek stel elke toepassing bloot aan die tonnel se maksimum pakkiegrootte. Toepassings wat buite die tonnel gewerk het, is nou dalk afhanklik van fragmentasiegedrag waaraan jy nooit hoef te dink het nie.

Bevestig dat plaaslike dienste en private DNS nog werk

Rangskik wat plaaslik moet bly volgens protokol eerder as volgens toepassingsnaam: ontdekkingsprotokolle vir drukkers en skerms, ’n slimhuis-brug, ’n router se bestuursbladsy, ’n plaaslike ontwikkelbediener wat bereik word met ’n naam wat net op die LAN opgelos word. Dié breek wanneer die verstekroete in ’n tonnel begin wys, en hulle breek stilweg omdat niks ’n fout by die kliënt aanteken nie.

Private DNS is die ander afhanklikheid. As interne name vroeër deur die tonnel se oplosser opgelos is, verander niks; as hulle plaaslik opgelos is, moet ’n volle verstek hulle na ’n oplosser dra wat die sones ken. Toets een interne naam en een openbare naam ná die verandering eerder as om te aanvaar dat die oplosserlys oorleef het.

Skryf die plaaslike uitsonderings in die profiel wat aan hulle behoort. ’n Uitsondering wat net in iemand se geheue gehou word, is die eerste ding wat die volgende migrasie verloor.

Migreer een profiel en verifieer die grense

Verander die profiel deur sy eie konfigurasie eerder as om ’n nuwe verstek bo-op handmatige roetes te lê wat vroeëre eksperimente agtergelaat het. Daardie oorblywende roetes is die gewone oorsaak van ’n migrasie wat werk lyk en ’n dag later onbestendig optree. Hou die ou profiel beskikbaar sodat ’n terugrol ’n keuse is eerder as ’n herbou.

Verifieer dan twee grense afsonderlik: dat openbare en private bestemmings albei werk, en dat ongewenste verkeer nie buite die tonnel uitgaan nie. ’n Suksesvolle bladsylading bewys die eerste en sê niks oor die tweede nie.

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

Herhaal die kontrole ná ’n herverbinding en ná ’n onderbreking, want ’n kill switch wat verkeer tydens ’n onderbreking blokkeer, is ’n ander eienskap as ’n roete wat daarna korrek herstel. Die eenvoudiger ontwerp is die een waarvan jy die werklike dekking nog kan verduidelik nadat ’n toepassing of ’n netwerk verander het.