OpenVPN-klient for hele LAN-et på OpenWrt: en arbeidsrekkefølge

Eierskap til grensesnittet, sone-policy, masquerade og tabeller per SSID er fire separate jobber. Gjør dem i rekkefølge, og tunnelen som dekker hele ruteren slutter å kjempe mot deg.

Fire uavhengige jobber setter hele LAN-et til en ruter bak én tunnel. Tunnelenheten trenger en eier, en brannmurssone, et oversettelsesmål mot opplenken og, hvis noen klienter må holde seg utenfor VPN-en, ruting etter kildeadresse. En tunnel som kobler til mens ingenting går gjennom, mangler vanligvis ett av de fire. Å arbeide i avhengighetsrekkefølge betyr at en feil på slutten tilhører trinnet du nettopp endret. Hvert trinn nedenfor avsluttes med noe du kan se, og det holder det neste fra å bli en gjetning.

Bestem hva som deler tunnelen

Ruteren som deler ut Wi-Fi og DHCP kan kjøre klienten selv. Det setter hver tilkoblede enhet bak tunnelen uten oppsett per enhet, og det er ordningen de fleste små anlegg ønsker. Det er også den med størst skadeomfang når tunnelen faller, fordi hver enhet mister ruten sin samtidig. Ingenting på LAN-et beholder en fungerende vei ut.

En andre ruter bak den første, som kjører klienten med sitt eget subnett, begrenser tunnelen til sine egne enheter. Den er lettere å fjerne og lettere å forklare for den som arver den. Prisen er nåbarhet mellom de to sidene uten en rute eller en portvideresending.

Enten det ene eller andre, gjør LAN-subnettene forskjellige. Identiske områder får den ene siden til å se direkte tilkoblet ut, og det resulterende svarte hullet leses som en VPN-feil i timevis.

Gi tunnelen en eier

Erklær tunnelen som et nettverksgrensesnitt med et navn, en enhet og ingen egen protokoll. Nettverkssystemet oppretter og administrerer da enheten, og alt nedstrøms refererer til grensesnittet ved navn i stedet for ved enhet. Det er det som lar sonen finne den.

Ikke opprett samme enhet to steder. En håndlaget tunnel ved siden av et erklært grensesnitt gir en enhet som finnes, men ikke er i en sone, eller en som forsvinner ved omlasting. Begge ser ut som klienten feilet, og ingen av dem gir en feil som navngir den virkelige årsaken. Velg den deklarative veien og slett den manuelle.

Hold navnet identisk i nettverks-, brannmur- og VPN-konfigurasjonen. Sonen lister nettverk ved navn, så en skrivefeil lar tunnelen stå utenfor hver sone mens grensesnittet selv ser friskt ut. Et friskt grensesnitt uten policy er den vanskeligste tilstanden å oppdage.

Sett den i en sone, og videresend så inn i den

En brannmurssone er der policyen bor: input, output, forward og masquerade. En tunnel som ikke er i noen sone, styres av standardverdier du ikke valgte, og det er sjelden det en ruterklient trenger. Blokkene nedenfor erklærer grensesnittet, plasserer det i en sone og tillater LAN-trafikk inn i den sonen.

config interface 'vpn'
    option device 'tun0'
    option proto 'none'

config zone
    option name 'vpn'
    list network 'vpn'
    option input 'REJECT'
    option output 'ACCEPT'
    option forward 'REJECT'
    option masq '1'

config forwarding
    option src 'lan'
    option dest 'vpn'

På utgivelser eldre enn 21.02 skrives samme grensesnittlinje som option ifname, så sjekk hvilken form den installerte fastvaren tolker før du limer inn. Videresendingsblokken er tillatelsen som lar LAN-trafikk bruke tunnelen i det hele tatt. Uten den er enheten oppe, klienten tilkoblet, og ingen LAN-vert når tunnelen. Det er den vanligste rapporten om tilkoblet men uten internett på ruterklienter.

Masquerade på VPN-sonen kollapser hver LAN-adresse til ruterens tunneladresse før pakken forlater. Det fjerner behovet for en returrute til subnettet ditt på den andre siden.

Hvis den andre siden allerede ruter LAN-et ditt, holder avslått masquerade kildeadressene synlige og gjør logger per klient meningsfulle. Velg én og skriv ned hvilken, fordi de to valgene gir forskjellige støttespørsmål senere. Å fjerne standardvideresendingen fra LAN til WAN er en separat beslutning med sin egen konsekvens. Tar du den bort, forsvinner ruterens egen internettilgang med den.

Navngi den virkelige opplenken i NAT

På fastvare der oversettelsesregelen er håndskrevet, er det utgående grensesnittet feltet som går galt. En regel som navngir vlan2 gjør ingenting når sesjonen avsluttes på ppp0. En regel uten noe grensesnitt kan oversette trafikk som burde ha forblitt privat. Ingen av feilene kunngjør seg selv, fordi tunnelen fortsetter å virke.

iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE

Erstatt ppp0 i den regelen med grensesnittet fra ip route eller den kjørende grensesnittlisten, og se så på telleren mens en LAN-vert laster en side. På en ruter med én leverandør er én masquerade-regel for opplenken normalt nok. En andre regel for tunellgrensesnittet er ikke en erstatning for den første.

Legg så til klientvalgene som bestemmer hva som kommer inn i tunnelen. Et redirect-gateway-direktiv sender klientens internettrafikk gjennom VPN-en, og uten det bærer tunnelen bare rutene serveren dytter. Sjekk den resulterende rutetabellen før du rører DNS.

Del Wi-Fi-en med en andre tabell

Én rutetabell kan ikke holde to standardruter. En andre SSID som må omgå tunnelen trenger derfor sitt eget subnett og sin egen tabell. Gi den tunnelerte SSID-en sitt eget område, og rut så bare det området inn i tunnelen med en regel som velger tabellen.

Policy-ruting-pakker på OpenWrt uttrykker akkurat den kombinasjonen. Det går også for hånd, med en kilderegel og en tabell hvis standard peker på tunellenheten.

Sjekk delingen fra begge nettverkene. En klient på den tunnelerte SSID-en skal vise VPN-ens utgangsadresse, og en klient på den vanlige SSID-en skal vise leverandørens. Når begge ser like ut, matcher regelen feil kilde eller tabellen blir aldri konsultert. Test også etter en gjentilkobling, fordi en regel som avhenger av grensesnittnavnet, brytes når enheten får nytt nummer.

Mistenk klokken og enhetsflagget

Flagget persist-tun lar tunellenheten bli liggende på plass gjennom omstarter. Det passer en server og forvirrer en klient hvis tilstand skal bygges opp på nytt. Fjern det mens du feilsøker en ruterklient, fordi en enhet som overlever en mislykket forhandling skjuler hvilket trinn som faktisk brøt. Sett det tilbake når klienten kobler til pålitelig, og ikke før.

Klokken er den andre stille feilen. En ruter uten batteriklokke starter ved epoken, som betyr at sertifikatsjekker feiler til NTP kommer på plass. Sammenlign loggtidsstemplene med virkelig tid før du rører et sertifikat, fordi en klient som kobler til et minutt etter oppstart, vanligvis venter på tidssynkronisering.

Relaterte artikler