OpenWrt VPN-sone, deurstuur en adresvermoming: watter een het jy nodig?

Daar raak drie veranderinge deurmekaar wanneer 'n VPN en OpenWrt mekaar ontmoet: om 'n poort oop te maak, om deurstuur toe te laat en om adresvermoming aan te skakel. Hulle beantwoord verskillende vrae, en gewoonlik is net een van hulle die werklike vereiste. As jy elke beheer lees volgens die verkeersrol wat dit bestuur, word 'n raaiskoot 'n besluit, en dit sê ook watter simptoom om te verwag wanneer die verandering verkeerd is. Begin deur die rol te benoem wat gefaal het, nie die merkie wat jy onthou nie.

Benoem eers die verkeersrol voordat jy aan 'n beheer raak

Sone-invoer besluit wat die router self mag bereik. Sone-uitvoer dek verkeer wat die router self begin, sone-deurstuur is die verstek vir verkeer wat deur 'n sone gaan, en adresvermoming besluit of die bronadres op pad uit herskryf word. Dit is vier verskillende vrae, en 'n sonebeleid beantwoord al vier gelyktydig met dieselfde waarde, en daarom is 'n sonewye verandering 'n growwe instrument. 'n Benoemde reël kan een van hulle beantwoord sonder om die res te raak.

Die nuttige kaart is volgens verkeersrol, want dit is wat jy kan waarneem wanneer iets faal. Elke rol hieronder het een beheer wat dit bepaal en een simptoom wat daarop wys:

Wat op die router luister, het een smal invoerreël nodig

'n OpenVPN-bediener op die router ontvang verkeer wat aan die router gerig is, so sy buitenste verbinding hang af van die invoerbeleid van die sone wat dit dra. Laat die gekonfigureerde transport en poort toe en laat alles anders in daardie sone verwerp. 'n Enkele poortreël is 'n baie kleiner verandering as 'n sonewye aanvaarding, en dit is die een wat jy nog oor 'n jaar kan verduidelik.

Twee dinge maak daardie reël veilig om te hou: dit noem die poort wat die diens werklik gebruik, en dit staan langs die sone-definisie sodat die volgende persoon sien waarom dit bestaan. Die reëls hieronder is die vorm, met die poort as plekhouer vir wat die bediener ook al gebruik. Verander daardie poort op albei plekke wanneer die diens skuif, want 'n reël wat op die oue bly staan, is onsigbaar tot 'n oudit.

config zone
    option name 'wan'
    option input 'REJECT'
    option forward 'REJECT'
    option output 'ACCEPT'
    option masq '1'

config rule
    option name 'allow-openvpn'
    option src 'wan'
    option proto 'udp'
    option dest_port '1194'
    option target 'ACCEPT'

Valideer voordat jy herlaai, want 'n sintaksfout in 'n firewall-lêer kan die router sonder 'n werkende reëlstel laat. Op 'n uitgawe wat fw4 gebruik, is die kontrole 'n aparte opdrag, en dit misluk hard eerder as om stilweg 'n stukkende blok te aanvaar. Herlaai eers nadat die kontrole geslaag het, en hou die vorige lêer waar jy dit kan terugsit.

fw4 check
service firewall reload

'n Kliëntversoek kruis deurstuur, nie invoer nie

Na verifikasie lewer 'n tonnelkliënt wat 'n LAN-diens vra, 'n deurgestuurde vloei, so die beheer wat dit bepaal, is die deurstuurverhouding tussen die tonnelsone en die LAN-sone. Wys die tonnelkoppelvlak aan die bedoelde sone toe, en verklaar dan die rigting, die bronne en die diens. Die sonetoewysing is wat die deurstuur-reël enige betekenis gee, en die twee maak net sin as 'n mens hulle saam lees. 'n Deurstuurverhouding wat die tonnelsone as bron en die LAN-sone as bestemming noem, lees as een doelbewuste besluit, terwyl twee sonewye aanvaardings as 'n ongeluk lees.

Om die router self te bereik, gebruik steeds die invoerpad, en daarom sê 'n ping na die poortwag niks oor die lêerdeling daar agter nie. Daardie twee foute woon in verskillende blokke en word met verskillende wysigings reggemaak. Skryf albei paaie afsonderlik neer voordat jy enigeen verander.

Adresvermoming is 'n roetebesluit, nie 'n toestemming nie

Adresvermoming herskryf die bronadres van geselekteerde uitgaande verkeer. Dit kan 'n uitgangsontwerp red waar die ander kant geen roete terug het nie, en dit verberg ook individuele kliëntadresse van enige diens wat adresse teken of magtig. Om dit af te skakel, is 'n roetekeuse oor die terugpad, nie 'n sekuriteitskakelaar wat 'n inkomende gat sluit nie. 'n Tonnel wat werk met omvorming aan en die oomblik swig wanneer dit afgeskakel word, het gewoonlik 'n ontbrekende terugroete, nie 'n ontbrekende firewall-reël nie.

'n Gerouteerde alternatief het 'n terugroete aan die ander kant nodig in plaas van omvorming. Nie een van die opsies verskaf die firewall-toestemming of die toepassingrekening nie, en daarom maak dit byna nooit 'n tonnelkliënt reg wat niks kan bereik nie. Behandel IPv4- en IPv6-beleid ook afsonderlik, want een omvormingsinstelling beskryf nie albei families nie.

Bewys die besluit met een toegelate en een geweierde versoek

Stuur een versoek wat toegelaat moet word en een wat geweier moet word, en identifiseer dan die beheer wat elke besluit geneem het. 'n Bladsy wat toevallig laai, is nie bewyse nie; die bewys is die reël wat gepas het, in die ketting wat dit gepas het. Die weiering maak net soveel saak as die sukses, want dit wys die beleid doen iets eerder as dat alles toegelaat word.

Twee opdragte gee jou daardie bewys op 'n huidige uitgawe. Die teller op die passende reël beweeg wanneer die versoek aanvaar word, en die log wys die drop as jy aantekeninge vir daardie reël geaktiveer het:

nft list chain inet fw4 forward_wan
logread -f | grep -i -E 'DROP|REJECT'

Hou 'n administrasiepad wat jy nog kan gebruik voordat jy enige firewall-beleid verander, en volg die eienaar van die konfigurasie se validerings- en terugrolproses. 'n Verandering wat jou uit die router sluit, is nie 'n toetsresultaat nie, dit is 'n tweede voorval. Teken die sone en die verkeersrol langs elke waarneming aan, sodat die paar resultate die beleid verduidelik in plaas daarvan om 'n gelukkige bladlaai te beskryf.