Hvem eier adressen, ruten, DNS-en og brannmuren på en Linux-VPN?
En Linux-VPN trenger én myndighet per objekt: enhet, adresse, ruter, DNS, brannmur. Skriv ned kartet, og definer deretter hva oppstart, gjenoppkobling og nedrigging gjenoppretter.
To skript som kjemper om den samme ruten er den vanlige formen for et Linux-VPN-problem som blir registrert som en rutingsfeil. Én komponent oppretter tunellenheten, en annen legger til en standardrute, en tredje skriver om resolver-konfigurasjonen, og en fjerde laster inn brannmurregler på nytt. Enhver av dem kan oppheve en annens arbeid, og vinneren er rett og slett den som kjørte sist. Spørsmålet som er verdt å svare på er ikke hvilken pakke som skal installeres, men hvilken komponent som har myndighet over hver del av tilstanden.
Skriv ned det kartet én gang, og de fleste gjenoppkoblingsfeil slutter å være mystiske. Fire objekter betyr noe: enheten og adressene dens, rutene og policyreglene, DNS-konfigurasjonen og brannmuren.
Enheten og adressene dens
En tunellenhet opprettes enten av en behandler som kjenner profilen, eller av en daemon som noen startet for hånd. Begge ordningene virker for seg selv; å blande dem gjør ikke. Hvis NetworkManager eier profilen, la den også eie enheten, og ikke start en uhåndtert OpenVPN-prosess mot det samme tunnelnavnet.
Noter hvem som fjerner enheten når økten avsluttes. En enhet som overlever økten sin, er den vanligste kilden til utdaterte adresser og til forvirringen som følger.
Ruter og policyregler
Det er på rutene at eierskapskonflikter gjør synlig skade. En tilkoblingsbehandler installerer en standardrute for tunellen pluss en mer spesifikk rute for fjernnettverket; et håndskrevet skript legger deretter til sin egen standardrute med en annen metrikk og vinner eller taper stille avhengig av tidspunktet. Bestem hvilke oppføringer som er tilkoblingsbundne, hvilke som er permanent policy, og hvilken komponent som oppdaterer dem etter en gjenoppkobling. Hold deretter de andre komponentene ute av den tabellen.
Policyregler fortjener den samme klarheten, for en regel som peker på en tabell som ingen fyller ut, produserer et svart hull som ser nøyaktig ut som en død tunell. Hvis en regel finnes for å tvinge trafikk et sted, må tabellen den velger, vedlikeholdes av den samme eieren.
DNS er alltid en separat eier
En resolver-daemon kjører som sin egen prosess under sin egen identitet, så den arver ikke tunellens rutingbeslutninger ved et uhell. Når VPN-en skyver DNS-servere, må noe oversette det til en konfigurasjon per lenke som resolveren respekterer, og noe må fjerne den etterpå.
Myten her er at det å skrive en navneserver i profilen endrer hvor spørringene går. Det endrer hva resolveren blir fortalt, ikke hvilken socket resolveren bruker oppstrøms. Test med en spørring pluss et ruteoppslag i stedet for å stole på filen.
Brannmurtilstanden, og hvem som gjenoppretter den
Brannmurregler er objektet som oftest overskrives på en VPN-vert. En behandler kan legge til NAT- eller videresendingsregler per tilkobling, mens en brannmurtjeneste ved oppstart laster inn et lagret regelsett på nytt og sletter dem. Velg én myndighet for policyen og gjør den andre til en forbruker av den, eller godta at en omstart stille endrer oppførselen. Tilkoblingsbundne unntak hører hjemme i en fil som den samme eieren laster, ikke i en iptables-kommando som skrives inn under feilsøking.
Hvis regler må overleve en gjenoppkobling, si det eksplisitt. Hvis ikke, si det også, for den neste ingeniøren vil anta det mest bekvemme svaret.
Livssyklus: oppstart, gjenoppkobling, nedrigging
Gi hvert av de tre øyeblikkene en eier. Ved oppstart, bestem hva som forbereder forutsetningene og i hvilken rekkefølge. Ved en myk omstart, husk at enheten kan overleve mens øktstilstanden ikke kan, så en validator må kjøre i stedet for en skaper. Ved nedrigging, fjern bare det denne tilkoblingen opprettet, for å tilbakestille hver rute eller tømme hele brannmuren er ikke det samme som å ta én tunell ut av drift.
Til observasjon viser ip monitor link address route kjerneendringer etter hvert som de skjer, men det rapporterer hendelser snarere enn hensikt: en slettet rute sier ingenting om hvilken prosess som slettet den. Par det med eierskapskartet, og en forvirrende nedstenging blir en kort liste med kandidater.
Unntak har også en pris. Å merke en hel enhetsklasse som uhåndtert for å unnslippe en konflikt gir den tilstanden til ingen, noe som er en beslutning snarere enn en rettelse.