En enda URL för kontoret och VPN? Varför myten om tillåtelselistan faller

Anslut tunneln, öppna samma bokmärke, och den tillåtna webbplatsen svarar exakt som den gjorde från kontoret. Det är antagandet som de flesta fjärråtkomstplaner tyst vilar på, och det håller bara så länge tre separata saker är sanna samtidigt. Ingen av dem är en funktion i VPN-klienten, och ingen DNS-post kan leverera någon av dem. När bokmärket misslyckas hemma ger webbläsaren dig ett enda generiskt fel, oavsett om orsaken är en saknad rutt, en icke godkänd utgångsadress eller en proxy som ersatt den källa den rapporterar. Att behandla de tre som ett enda problem är vägen där en liten policyrättelse blir en vecka av att utöka tillåtelselistor.

Den design som överlever mötet med ett riktigt kontorsnätverk är snävare än antagandet: en uttrycklig beslutstabell med tre rader, en genomdrivningspunkt som inte kan kringgås och ett avvisningstest som bevisar något. Att plocka isär antagandet kommer först, eftersom allt därefter beror på att veta vilket lager som framställer källan fel.

Myten: att ansluta är inte att routa

En tunnel upprättas och klienten installerar rutter för en viss uppsättning prefix. Det är allt som anslutning gör. Huruvida en orelaterad HTTPS-begäran färdas genom tunneln, och från vilken offentlig adress den verkar komma när den anländer, är beslut som andra komponenter fattar senare: rutttabellen väljer vägen och utgången väljer källan.

Därför skiljer sig kontoret och köksbordet med samma bärbara dator, samma webbläsarprofil och samma bokmärke. På kontoret lämnar begäran genom en underhållen offentlig adress som webbplatsens operatör har godkänt. Genom en full tunnel kan den lämna genom VPN-utgången, som är en annan adress och, tills någon lägger till den, en icke godkänd sådan. Genom en delad tunnel kommer den kanske aldrig in i tunneln. Bara två av dessa tre vägar var någonsin en del av avtalet med webbplatsens ägare, och den tredje är inte ett fel som ska lappas med en extra allow-rad.

Tre begärandetillstånd, två godkända utgångar

Skriv ned matrisen innan du rör en brandvägg, eftersom tabellen är designen och regeln bara är en implementering av den. Adresserna nedan är dokumentationsintervall; ersätt dem med dina egna underhållna värden och förvara dem där webbplatsens ägare kan granska dem.

Den mellersta raden är där de flesta av dessa planer brister. Det som räknas är adressen som genomdrivningsenheten ser, inte den privata adressen som den bärbara datorn har inne i tunneln och inte dess LAN-adress. Ett värde som 10.8.0.6 betyder ingenting för en offentlig webbplats, och det gör 192.168.1.44 inte heller. En tunneladress är en adresseringsdetalj för tunneln, inte en legitimation som webbplatsen kan kontrollera.

Om din VPN inte kan tillhandahålla en stabil, dokumenterad utgång har matrisen ingen giltig mellersta rad, och ingen mängd tillåtelselistor hittar på en. De ärliga alternativen är då en privat webbplats som nås via uttryckliga privata rutter, eller en identitetsmedveten åtkomstportal framför applikationen. Båda har ett annat avtal än en offentlig tillåtelselista, och båda är lättare att förklara för en granskare än en lista som växte tills den råkade fungera.

Läs källan där beslutet fattas

Sätt begränsningen på enheten som avslutar begäran och bekräfta att ingen alternativ ursprungsväg går förbi den. Nginx åtkomstmodul utvärderar allow- och deny-direktiven i ordning, första träffen vinner, och regler som ärvts från ett omslutande block gäller fortfarande inne i location. En smal allow bredvid en bred allow på samma ställe betyder oftast att den breda bestämmer. Läs hela den effektiva konfigurationen för den locationen innan du redigerar en enda rad av den.

server {
    listen 443 ssl;
    server_name intranet.example.com;

    set_real_ip_from 10.20.0.10;
    real_ip_header X-Forwarded-For;
    real_ip_recursive on;

    location /app/ {
        allow 203.0.113.24;    # office public exit
        allow 198.51.100.77;   # approved VPN egress
        deny  all;
        proxy_pass http://app_backend;
    }
}

Bakom en lastbalanserare eller omvänd proxy ser den regeln proxyn om du inte säger annat till den. Återställ bara anroparens adress genom den stödda betrodda-proxymekanismen, med en uttrycklig lista över proxyadresser. En begäranrubrik som hävdar en godkänd adress är inte bevis för att anroparen äger den, och på en offentlig lyssnare gör en ovaliderad vidarebefordrad rubrik tillåtelselistan till dekoration.

Kontrollera sedan den andra adressfamiljen. En regeluppsättning som bara täcker IPv4 är ett ofullständigt beslut för ett värdnamn som också svarar på AAAA, och en klient med fungerande IPv6 når samma applikation via en väg du aldrig har granskat.

Delad tunnel: begäran som aldrig kommer in

En delad tunnel bär bara de prefix som finns på dess lista. Interna kontorssubnät finns oftast på den listan; en offentlig webbplats inte. Webbläsaren löser namnet, jämför den valda adressen med rutttabellen och hittar ändå den lokala standardgatewayen framför sig.

Så kommer begäran från användarens hemuppkoppling, avvisas, och rapporten säger att VPN:en är trasig medan tunneln gör exakt det den konfigurerades för. Två rättelser är legitima: rutta den destinationen genom tunneln och låt den godkända utgången bära den, eller acceptera att webbplatsen nås direkt och ge fjärranvändare en annan godkänd väg, till exempel åtkomstportalen. Att utöka webbplatsens offentliga tillåtelselista tills en hemadress råkar ingå är inget av dem, och det tar bort den gräns som designen skulle genomdriva. De två första håller matrisen ärlig; den tredje raderar tyst en rad ur den.

Bevisa avvisningen, sedan återställningen

Testa med en begäran som utövar det verkliga beslutet, från en klient som står på varje rad i tabellen. En nåbarhetskontroll mot någon orelaterad adressvisande sida bevisar ingenting, eftersom den destinationen kan följa en annan väg än applikationen.

curl -sS -o /dev/null -w 'status=%{http_code}
' https://intranet.example.com/app/login
# repeat with the tunnel up, then with it down
tail -f /var/log/nginx/access.log | grep ' /app/'

Jämför åtkomstloggen vid gränsen med vad tabellen förutsade. Sänk sedan tunneln och gör en ny begäran som borde avvisas; en sida som redan laddats, eller en anslutning som redan är öppen, testar ingenting alls. Om ingen avvisning visas är genomdrivningspunkten inte där du tror.

Behåll applikationsautentiseringen efter nätverksinträdet, eftersom en kontorsutgång och en VPN-utgång var och en representerar många människor och ingen av dem identifierar en individ. Instruktionen till användarna förblir kort: res den godkända tunneln och försök sedan igen. Det är detta som håller en enda URL bekväm medan källregeln förblir ett beslut och inte en gissning.