OpenVPN-klient för hela LAN-et på OpenWrt: en arbetsordning

Fyra oberoende jobb sätter hela LAN-et på en router bakom en enda tunnel. Tunnelenheten behöver en ägare, en brandväggszon, ett översättningsmål mot upplänken och, om vissa klienter måste hållas utanför VPN, routning efter källadress. En tunnel som ansluter medan inget passerar saknar vanligtvis en av de fyra. Att arbeta i beroendeordning betyder att ett fel i slutet tillhör steget du just ändrade. Varje steg nedan slutar med något du kan se, och det hindrar nästa från att bli en gissning.

Bestäm vad som delar tunneln

Routern som delar ut Wi-Fi och DHCP kan köra klienten själv. Det sätter varje ansluten enhet bakom tunneln utan inställning per enhet, och det är upplägget de flesta små anläggningar vill ha. Det är också det med störst skadeomfång när tunneln faller, eftersom varje enhet tappar sin väg på en gång. Inget på LAN-et behåller en fungerande väg ut.

En andra router bakom den första, som kör klienten med eget subnät, begränsar tunneln till sina egna enheter. Den är lättare att ta bort och lättare att förklara för den som ärver den. Priset är nåbarhet mellan de två sidorna utan en rutt eller en portvidarebefordran.

Hur som helst, gör LAN-subnäten olika. Identiska intervall får ena sidan att se direktansluten ut, och det resulterande svarta hålet läses som ett VPN-fel i timmar.

Ge tunneln en ägare

Deklarera tunneln som ett nätverksgränssnitt med ett namn, en enhet och utan eget protokoll. Nätverkssystemet skapar och hanterar då enheten, och allt nedströms refererar till gränssnittet med namn i stället för med enhet. Det är det som låter zonen hitta den.

Skapa inte samma enhet på två ställen. En handgjord tunnel bredvid ett deklarerat gränssnitt ger en enhet som finns men inte är i någon zon, eller en som försvinner vid omladdning. Båda ser ut som att klienten misslyckades, och ingen av dem ger ett fel som namnger den verkliga orsaken. Välj den deklarativa vägen och ta bort den manuella.

Håll namnet identiskt i nätverks-, brandväggs- och VPN-konfigurationen. Zonen listar nätverk med namn, så ett stavfel lämnar tunneln utanför varje zon medan gränssnittet självt ser friskt ut. Ett friskt gränssnitt utan policy är det svåraste tillståndet att upptäcka.

Sätt den i en zon och vidarebefordra sedan in i den

En brandväggszon är där policyn bor: in, ut, vidarebefordran och masquerade. En tunnel utan zon styrs av standardvärden du inte valde, och det är sällan vad en routerklient behöver. Blocken nedan deklarerar gränssnittet, placerar det i en zon och tillåter LAN-trafik in i den zonen.

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å utgåvor äldre än 21.02 skrivs samma gränssnittsrad som option ifname, så kontrollera vilken form den installerade firmwaren tolkar innan du klistrar in. Vidarebefordringsblocket är tillståndet som låter LAN-trafik använda tunneln över huvud taget. Utan det är enheten uppe, klienten ansluten, och ingen LAN-värd når tunneln. Det är den vanligaste rapporten om ansluten men utan internet på routerklienter.

Masquerade på VPN-zonen pressar ihop varje LAN-adress till routerns tunneladress innan paketet lämnar. Det tar bort behovet av en returrutt till ditt subnät på andra sidan.

Om andra sidan redan routar ditt LAN behåller avstängd masquerade källadresserna synliga och gör loggar per klient meningsfulla. Välj en och skriv ned vilken, eftersom de två valen ger olika supportfrågor senare. Att ta bort standardvidarebefordran från LAN till WAN är ett separat beslut med egen konsekvens. Tar du bort den försvinner routerns egen internetåtkomst med den.

Namnge den verkliga upplänken i NAT

På firmware där översättningsregeln är handskriven är det utgående gränssnittet fältet som går fel. En regel som namnger vlan2 gör ingenting när sessionen avslutas på ppp0. En regel helt utan gränssnitt kan översätta trafik som borde ha förblivit privat. Ingen av felen tillkännager sig, eftersom tunneln fortsätter att fungera.

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

Ersätt ppp0 i den regeln med gränssnittet från ip route eller den körande gränssnittslistan, och titta sedan på räknaren medan en LAN-värd laddar en sida. På en router med en leverantör räcker normalt en masquerade-regel för upplänken. En andra regel för tunnelgränssnittet är ingen ersättning för den första.

Lägg sedan till klientalternativen som bestämmer vad som kommer in i tunneln. Ett redirect-gateway-direktiv skickar klientens internettrafik genom VPN, och utan det bär tunneln bara de rutter servern trycker ut. Kontrollera den resulterande rutttabellen innan du rör DNS.

Dela Wi-Fi med en andra tabell

En rutttabell kan inte hålla två standardrutter. En andra SSID som måste kringgå tunneln behöver därför eget subnät och egen tabell. Ge den tunnlade SSID ett eget intervall och routa sedan bara det intervallet in i tunneln med en regel som väljer tabellen.

Policy-routing-paket på OpenWrt uttrycker precis den kombinationen. Det går också för hand, med en källregel och en tabell vars standard pekar på tunnelenheten.

Kontrollera delningen från båda nätverken. En klient på den tunnlade SSID ska visa VPN:ens utgångsadress, och en klient på den vanliga SSID leverantörens. När båda ser likadana ut matchar regeln fel källa eller så konsulteras aldrig tabellen. Testa även efter en återanslutning, eftersom en regel som beror på gränssnittsnamnet går sönder när enheten får nytt nummer.

Misstänk klockan och enhetsflaggan

Flaggan persist-tun låter tunnelenheten ligga kvar mellan omstarter. Det passar en server och förvirrar en klient vars tillstånd ska byggas upp från grunden. Ta bort den medan du felsöker en routerklient, eftersom en enhet som överlever en misslyckad förhandling döljer vilket steg som faktiskt gick sönder. Sätt tillbaka den när klienten ansluter pålitligt, och inte före.

Klockan är det andra tysta felet. En router utan batteriklocka startar vid epoken, vilket betyder att certifikatkontroller misslyckas tills NTP kommer ikapp. Jämför loggens tidsstämplar med verklig tid innan du rör ett certifikat, eftersom en klient som ansluter en minut efter start vanligtvis väntar på tidssynkronisering.