VPN-router: LAN och WAN — vad du bör dokumentera före köpet
En VPN-etikett säger ingenting om VLAN, WAN-failover eller tunnelroller. Skriv ner de exakta förmågorna för den modell och firmware du tänker använda.
Behandla en VPN-klar-etikett som en egenskap hos en enhet som också måste routa, segmentera och växla vid fel, eftersom etiketten inte säger något om hur många separata nät enheten kan hålla. Börja med att skriva en förmågeprotokoll för den exakta modellen och firmwaren och jämför sedan protokollet med de flöden som platsen behöver. Marknadssidor listar kontakter; de listar sällan VLAN-medlemskap, failover-policy eller tunnelomfång. Protokollet tar ungefär tjugo minuter och avgör de flesta köpdiskussioner innan hårdvaran anländer.
Fäst den exakta enheten före allt annat
Modellnamn reser mellan firmwaregenerationer, och samma kapsling kan levereras med en annan switchdrivrutin beroende på utgåvan. Läs kortets identitet från enheten själv i stället för från kartongen, så att varje senare påstående är knutet till något du kan återskapa. Ett kommando täcker modell, kortnamn och firmwareutgåva på OpenWrt, och motsvarande skärmar finns i de flesta företagsfirmwares.
ssh [email protected] 'ubus call system board'
cat /etc/openwrt_release
Skriv in de strängarna i protokollet, aldrig förkortade. Separera sedan den vanliga routningsuppgiften från tunneluppgiften. En enhet som vidarebefordrar paket bra kan ändå vägra att avsluta en tunnel, och en enhet som avslutar en tunnel har kanske inget sätt att hålla två lokala nät åtskilda. Behandlas de båda som ett krav döljs avvikelsen tills enheten redan är monterad i rack, konfigurerad och halvt betrodd.
Notera LAN-strukturen, inte portantalet
Fyra kontakter betyder vanligen en switch, och en switch betyder en broadcastdomän om inte VLAN är konfigurerade. Det är bra för ett platt hemnät och fel för en plats som vill ha ett gästsegment, ett administrationssegment och ett isolerat kamerasegment på samma enhet. Notera vilka portar som hör till vilket VLAN, vilka VLAN som når CPU:n och vilka gränssnitt som bär adresser.
Där firmwaren erbjuder VLAN avgör gränssnittslistan hur många olika policyer du kan skriva. Ett VLAN som definieras på switchen men aldrig tilldelas som gränssnitt har ingen adress och ingen brandväggszon, så det kan inte genomdriva något på egen hand.
| Field to record | Example entry | Review stops if |
|---|---|---|
| Ports and VLAN membership | ports 1-4 untagged on VLAN 10, port 5 trunk with VLAN 10 and 20 | the datasheet offers only a socket count |
| Routed interfaces | br-lan 192.168.88.1/24, vlan20 192.168.99.1/24 | two subnets cannot hold separate policies |
| WAN method and failover | DHCP on wan, PPPoE on wan2, policy route to wan2 on loss | only one uplink is configurable |
| Tunnel role and scope | WireGuard peer on the router, only 192.168.88.0/24 routed inside | the router can only pass another tunnel through |
Läs switchstatusen i stället för att lita på menyn. På äldre OpenWrt-mål skriver switchverktyget ut de konfigurerade enheterna, och på DSA-mål rapporterar broverktygen samma fakta per port, därför hör firmwareutgåvan hemma i protokollet.
Skriv ner WAN- och failoverbeteendet
Åtkomstmetod, adressägande och failoverordning hör på en rad per upplänk, eftersom en tunnel som överlever en WAN-ändring beror på alla tre. En PPPoE-session återansluter med en ny adress och tappar tunneln med den, medan en DHCP-upplänk som behåller sin lease kanske inte gör det.
Failover kräver också ett policybeslut. Att skicka all trafik till backup-länken är enkelt; att hålla tunneln på den primära medan vanlig webbtrafik använder backupen kräver policyrouting, och inte all firmware erbjuder det. Notera om tunneln är bunden till en enda upplänk, och vad enheten gör med etablerade sessioner när den länken försvinner. Spara routingtabellen som bevis, inte failover-kryssrutan.
Testa ett tillåtet och ett nekat flöde
Protokollet är bara värt att behålla om enheten kan godtas mot det. Välj ett flöde som måste fungera, ett som inte får, och kör båda från en klient i det aktuella segmentet. En tunnel som bär varje subnät är ett misslyckande när kravet var ett subnät.
Bekräfta sedan nekandet, eftersom en tillåtande standard är den vanliga överraskningen. Gästsegmentet får inte nå administrationsadressen, och kontrollen bör visa en timeout eller ett nekande i stället för en inloggningssida.
curl -sS --max-time 8 https://api.ipify.org
ping -c 2 192.168.99.1
ip -4 route get 192.168.99.1
Om det tillåtna flödet fungerar och det nekade också fungerar saknas segmenteringen även om menyerna antydde motsatsen. Om båda misslyckas är tunnelomfånget eller returvägen fel, och WAN-protokollet förklarar vanligen vilket. Spara de två resultaten med förmågeprotokollet så att nästa granskare ser vad som godtogs, på vilken firmware och vilket datum.