OpenVPN-klient for hele LAN'et på OpenWrt: en rækkefølge, der virker

Fire uafhængige opgaver sætter hele routerens LAN bag én tunnel. Tunnelenheden skal have en ejer, en firewallzone, et oversættelsesmål mod uplinket og, hvis nogle klienter skal blive uden for VPN'et, routing efter kildeadresse. En tunnel, der forbinder, mens intet passerer, mangler som regel en af de fire. At arbejde i afhængighedsorden betyder, at en fejl til sidst hører til det trin, du lige har ændret. Hvert trin nedenfor slutter med noget, du kan observere, og det holder det næste fra at være et gæt.

Beslut hvad tunnelen deler

Routeren, der uddeler Wi-Fi og DHCP, kan selv køre klienten. Det sætter hver tilsluttet enhed bag tunnelen uden opsætning per enhed, og det er den ordning, de fleste små steder vil have. Det er også den med den bredeste effekt, når tunnelen falder, fordi alle enheder mister deres vej på én gang. Intet på LAN'et beholder en fungerende rute ud.

En anden router bag den første, som kører klienten med sit eget subnet, begrænser tunnelen til sine egne enheder. Den er lettere at fjerne og lettere at forklare den, der arver den. Prisen er nåbarhed mellem de to sider uden en rute eller en portvideresendelse.

Under alle omstændigheder, gør LAN-subnettene forskellige. Identiske områder får den ene side til at se direkte forbundet ud, og det sorte hul, der opstår, ligner en VPN-fejl i timer.

Giv tunnelen en ejer

Erklær tunnelen som et netværksinterface med et navn, en enhed og ingen egen protokol. Netværkssystemet opretter og styrer så enheden, og alt nedstrøms henviser til interfacet ved navn frem for ved enhed. Det er det, der lader zonen finde den.

Opret ikke den samme enhed to steder. En håndlavet tunnel ved siden af et erklæret interface giver en enhed, der findes, men ikke er i en zone, eller en, der forsvinder ved genindlæsning. Begge ser ud som om klienten fejlede, og ingen af dem giver en fejl, der navngiver den egentlige årsag. Vælg den deklarative vej, og slet den manuelle.

Hold navnet identisk i netværks-, firewall- og VPN-konfigurationen. Zonen lister netværk ved navn, så en tastefejl efterlader tunnelen uden for hver zone, mens interfacet selv ser sundt ud. Et sundt interface uden politik er den sværeste tilstand at få øje på.

Sæt den i en zone, og videresend så ind i den

En firewallzone er der, hvor politikken bor: input, output, forward og masquerade. En tunnel uden for enhver zone styres af standarder, du ikke har valgt, og det er sjældent, hvad en routerklient har brug for. Blokkene nedenfor erklærer interfacet, sætter det i en zone og tillader LAN-trafik ind i den zone.

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å udgivelser ældre end 21.02 skrives den samme interfacelinje som option ifname, så undersøg hvilken form den installerede firmware parser, før du indsætter. Videresendelsesblokken er den tilladelse, der overhovedet lader LAN-trafik bruge tunnelen. Uden den er enheden oppe, klienten forbundet, og ingen LAN-vært når tunnelen. Det er den mest almindelige melding om forbundet men intet internet hos routerklienter.

Masquerade på VPN-zonen folder hver LAN-adresse ind i routerens tunneladresse, før pakken forlader. Det fjerner behovet for en returrute til dit subnet på den anden side.

Hvis den anden side allerede router dit LAN, holder slukket masquerade kildeadresserne synlige og gør logfiler per klient meningsfulde. Vælg én, og skriv ned hvilken, fordi de to valg senere giver forskellige supportspørgsmål. At fjerne standardvideresendelsen fra LAN til WAN er en separat beslutning med sin egen følge. Fjern den, og routerens egen internetadgang går med.

Navngiv det rigtige uplink i NAT

På firmware, hvor oversættelsesreglen er håndskrevet, er det udgående interface det felt, der går galt. En regel, der navngiver vlan2, gør intet, når sessionen afsluttes på ppp0. En regel helt uden interface kan oversætte trafik, der skulle være forblevet privat. Ingen af fejlene melder sig selv, fordi tunnelen fortsætter med at virke.

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

Erstat ppp0 i den regel med interfacet fra ip route eller listen over kørende interfaces, og se så tælleren, mens en LAN-vært indlæser en side. På en router med én udbyder er én masquerade-regel til uplinket normalt nok. En anden regel til tunnelinterfacet erstatter ikke den første.

Tilføj så de klientvalg, der bestemmer, hvad der kommer ind i tunnelen. En redirect-gateway-direktiv sender klientens internettrafik gennem VPN'et, og uden den bærer tunnelen kun de ruter, serveren skubber. Kontroller den resulterende rutetabel, før du rører DNS.

Del Wi-Fi'et med en anden tabel

Én rutetabel kan ikke holde to standardruter. Et andet SSID, der skal omgå tunnelen, har derfor brug for sit eget subnet og sin egen tabel. Giv det tunnellede SSID sit eget område, og rut så kun det område ind i tunnelen med en regel, der vælger tabellen.

Policy-routing-pakker på OpenWrt udtrykker præcis den kombination. Det kan også gøres i hånden, med en kilderegel og en tabel, hvis standard peger på tunnelenheden.

Kontroller opdelingen fra begge netværk. En klient på det tunnellede SSID bør vise VPN'ets udgangsadresse, og en klient på det almindelige SSID bør vise udbyderens. Når begge ser ens ud, rammer reglen den forkerte kilde, eller tabellen bliver aldrig spurgt. Test også efter en genopkobling, fordi en regel, der afhænger af interfacenavnet, brækker, når enheden omnummereres.

Mistænk uret og enhedsflaget

Flaget persist-tun lader tunnelenheden blive på plads gennem genstarter. Det passer til en server og forvirrer en klient, hvis tilstand skal bygges op fra bunden. Fjern det, mens du fejlfinder på en routerklient, fordi en enhed, der overlever en mislykket forhandling, skjuler hvilket trin der faktisk brød. Sæt det tilbage, når klienten forbinder pålideligt, og ikke før.

Uret er den anden stille fejl. En router uden batteribacker ur starter ved epoken, hvilket betyder, at certifikattjek fejler, indtil NTP indhenter det. Sammenlign loggens tidsstempler med den rigtige tid, før du rører et certifikat, fordi en klient, der forbinder et minut efter opstart, som regel venter på tidssynkronisering.