VPN-kliënte en die LAN: wanneer om 'n aparte sone te gebruik

Om die tonnelkoppelvlak in die LAN-sone te plaas, is die kortste pad na 'n werkende VPN, en dit is gewoonlik die verkeerde verstek. Dit gee die afgeleë kliënt dieselfde vertroue as die bedrade LAN, wat selde is wat die taak vereis. 'n Aparte sone kos 'n paar reëls en maak die grens sigbaar. Die besluit is nie of sones beter is nie; dit is watter drie voorwaardes op jou netwerk van toepassing is.

Die sonenaam versyfer niks en verifieer geen gebruiker nie. Dit groepeer net koppelvlakke vir die firewall se beleidsmodel.

Wat sonelidmaatskap werklik beheer

'n Sone groepeer koppelvlakke of verkeer onder die firewall se model. Die input-, output- en forward-instelling daarvan bestuur dan verskillende rolle. Input is verkeer na die router self; forwarding is verkeer daardeur na 'n ander gasheer. OpenWrt se dokumentasie oor sones behandel input, output en forwarding juis daarom as afsonderlike instellings.

'n Toelating van die VPN-sone na die LAN-sone is nie outomaties 'n omgekeerde toelating nie. Forward-reëls het 'n rigting, en 'n reël wat kliënt-na-bediener-verkeer toelaat, laat nie bediener-na-kliënt-sessies toe nie. 'n Kliënt wat 'n verbinding na 'n bediener kan oopmaak, is nie 'n kliënt waarna die bediener 'n verbinding kan terugmaak nie.

Daardie onderskeid is die rede waarom 'n aparte sone nuttig is: jy kan elke rigting en elke rol eksplisiet stel. Skryf die rigting langs elke reël.

Besluit een: input, forward of albei

As afgeleë kliënte DNS van die router nodig het, laat input net vir daardie diens toe. As hulle 'n lêerbediener moet bereik, laat forward na daardie bestemming toe. Die meeste VPN-ontwerpe het albei nodig, maar vir verskillende dienste.

Wye input-toegang tot elke plaaslike diens is byna nooit nodig nie. Hanteer routerbestuur as 'n aparte besluit van toepassingstoegang. As die router net DNS hoef te antwoord, skryf daardie enkele toelating en laat die res gesluit.

Besluit twee: watter hulpbronne afgeleë kliënte nodig het

Lys die kliëntreekse, die bestemmings en die dienste wat die VPN moet bied voordat jy reëls skryf. 'n Bestemmingslys is nuttiger as 'n vertrouensetiket, want dit oorleef 'n firewall-migrasie.

Hou bestuurskoppelvlakke apart van gewone toepassingstoegang. 'n Afgeleë kliënt wat 'n wiki kan bereik, het daardeur nie die router se administrasiebladsy of die hipervisor-konsole nodig nie.

As 'n toegelate bestemming verder kan aanstuur, stop die sonegrens by die firewall, nie by wat die bestemming volgende doen nie.

Besluit drie: hoe jy die grens sal bewys

Toets 'n toegelate vloei en een wat doelbewus geweier word ná elke verandering. Om te bewys dat een webwerf laai, openbaar nie 'n onbedoelde wye toelating nie. Toets vanuit die VPN-kliënt se adresreeks, nie vanuit die LAN nie, en sluit die rigting in wat jy verwag om te misluk. Teken albei resultate langs die reël aan.

Bewaar die gateway se hersteltoegang voordat jy die beleid vir afgeleë sones wysig. Gebruik die volgehoue bestuurde konfigurasie eerder as wysigings tydens looptyd, anders sal die volgende herbegin die ou vertroue herstel. 'n Kopie van die vorige konfigurasie, buite die toestel gestoor, is die goedkoopste terugrol wat jy ooit sal hê.

Wanneer die netwerk groei, dokumenteer lidmaatskap en die doel van elke reël. 'n Nuut gekoppelde koppelvlak moet nie voorregte erf net omdat iemand dit 'n gerieflike sonenaam gegee het nie.