Ien URL foar kantoar en VPN? Wêrom’t de myte fan ’e talitlist mislearret

Ferken it tunnel, iepenje deselde blêdwizer, en de talitten side antwurdet krekt sa’t se dat fan it kantoar die. Dat is de oanname dêr’t de measte plannen foar tagong op ôfstân stil op rêste, en se jildt allinnich safier’t trije aparte dingen tagelyk wier bliuwe. Gjin fan allegear is in funksje fan ’e VPN-klant, en gjin DNS-record kin ien fan allegear leverje. As de blêdwizer thús mislearret, jout de browser jo ien algemiene flater, itsij de oarsaak in ûntbrekkende rûte is, in net-goedkard útgongsadres of in proxy dy’t de boarne ferfongen hat dy’t er rapportearret. Dizze trije as ien probleem behannelje is de wize dêr’t in lytse beliedsreparaasje in wike fan it ferbreedzjen fan talitlisten fan wurdt.

It ûntwerp dat kontakt mei in echt kantoarnetwurk oerlibbet is smeller as de oanname: in eksplisite beslissingstabel fan trije rigen, ien hanthaveningspunt dat net omgien wurde kin, en in weigeringsproef dy’t wat bewissiget. It ôfbrekken fan ’e oanname komt earst, want alles dêrnei hinget ôf fan it witten hokker laach de boarne ferkeard foarstelt.

De myte: ferbinen is net rûte

In tunnel wurdt oprjochte, en de klant ynstallearret rûtes foar in set foarheaksels. Dat is it hiele fan wat ferbinen docht. Oft in ûnôfhinklik HTTPS-fersyk troch de tunnel reizget, en fan hokker iepenbier adres it liket te kommen as it oankomt, binne beslissingen dy’t letter troch oare komponinten nommen wurde: de rûtetabel kiest it paad, en de útgong kiest de boarne.

Dêrom ferskille it kantoar en de keukentafel mei deselde laptop, deselde browserprofyl en deselde blêdwizer. Op it kantoar ferlit it fersyk in ûnderholden iepenbier adres dêr’t de operator fan ’e side mei ynstimd hat. Troch in folsleine tunnel kin it de VPN-útgong ferlitte, dat is in oar adres en, oant immen it tafoeget, in net-goedkard. Troch in splitstunnel komt it miskien hielendal net yn ’e tunnel. Mar twa fan dy trije paden makken ea diel út fan ’e oerienkomst mei de eigner fan ’e side, en it tredde is gjin brek dy’t mei in ekstra allow-rige reparearre wurde moat.

Trije fersyktastannen, twa goedkarde útgongen

Skriuw de matrix op foardat jo in fjoermuorre oanreitsje, want de tabel is it ûntwerp en de regel is mar ien útfiering dêrfan. De adressen hjirûnder binne dokumintaasje-berikken; ferfange se troch jo eigen ûnderholden wearden en bewarje se earne dêr’t de eigner fan ’e side se kontrolearje kin.

De middelste rige is dêr’t de measte fan dizze plannen brekke. Wat telt is it adres dat it hanthaveningsapparaat sjocht, net it private adres dat de laptop yn ’e tunnel hâldt en net syn LAN-adres. In wearde lykas 10.8.0.6 betsjut neat foar in iepenbiere side, en 192.168.1.44 ek net. In tunneladres is in adressearringsdetail fan ’e tunnel, gjin bewiisstik dat de side kontrolearje kin.

As jo VPN gjin stabile, dokumintearre útgong leverje kin, hat de matrix gjin jildige middelste rige en gjin hoemannichte talitlisten betinkt ien. De earlike opsjes op dat stuit binne in private side berikt oer eksplisite private rûtes, of in tagongsgateway dy’t bewust is fan identiteit foar de applikaasje. Beide hawwe in oar kontrakt as in iepenbiere talitlist, en beide binne makliker oan in auditor út te lizzen as in list dy’t groeide oant er tafallich wurke.

Lês de boarne dêr’t de beslissing nommen wurdt

Set de beheining op it apparaat dat it fersyk einiget, en befêstigje dat gjin alternatyf oarsprongpaad it omslûpt. Nginx-tagongsmodule evaluearret de allow- en deny-rjochtlinen yn oarder, de earste oerienkomst wint, en regels dy’t fan in omslutend blok erfd binne jilde noch hieltyd binnen location. In smelle allow njonken in brede allow op itselde plak betsjut meast dat de brede beslissing nimt. Lês de hiele effektive konfiguraasje foar dat location foardat jo ien rigel dêrfan bewurkje.

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;
    }
}

Efter in ladingbalansearder of in omkearde proxy sjocht dy regel de proxy, útsein as jo it oars fertelle. Werstel it adres fan ’e oanropper allinnich fia it stipe fertroude-proxymeganisme, mei in eksplisite list fan proxy-adressen. In fersykkop dy’t in goedkard adres beweart is gjin bewiis dat de oanropper it hat, en op in iepenbiere harker makket in net-falidearre trochstjoerde kop de talitlist ta fersiering.

Kontrolearje dan de oare adresfamylje. In regelset dy’t allinnich IPv4 beslacht is in ûnfolsleine beslissing foar in hostnamme dy’t ek op AAAA antwurdet, en in klant mei wurkjende IPv6 sil deselde applikaasje berikke fia in paad dat jo nea neisjoen hawwe.

Splitstunnel: it fersyk dat nea ynkomt

In splitstunnel ferfiert allinnich de foarheaksels op syn list. Ynterne kantoarsubnetten komme meast op dy list; in iepenbiere webside net. De browser lost de namme op, fergeliket it keazen adres mei de rûtetabel, en fynt dochs de lokale standertgateway foar him.

Sa komt it fersyk fan ’e thúsferbining fan ’e brûker, wurdt it wegere, en it rapport seit dat de VPN stikken is wylst de tunnel krekt docht wêr’t er foar konfigurearre is. Twa reparaasjes binne legitime: rûte dy bestimming troch de tunnel en lit de goedkarde útgong it drage, of akseptearje dat de side direkt berikt wurdt en jou brûkers op ôfstân in oar goedkard paad lykas de tagongsgateway. De iepenbiere talitlist fan ’e side ferbreedzje oant in thúsadres tafallich meirekkene wurdt is gjin fan beide, en it ferwideret de grins dy’t it ûntwerp hanthavenje moast. De earste twa hâlde de matrix earlik; de tredde wist stil in rige derfan.

Bewissigje de weigering, dan it herstel

Test mei in fersyk dat de echte beslissing útoefenet, fan in klant dy’t op elke rige fan ’e tabel stiet. In berikberensproef tsjin in ûnôfhinklike side dy’t it adres sjen lit bewissiget neat, want dy bestimming kin in oar paad folgje as de applikaasje.

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/'

Fergelykje it tagongsrecord op ’e grins mei wat de tabel foarsein hie. Set dan de tunnel del en meitsje in nij fersyk dat wegere wurde moat; in side dy’t al laden is, of in ferbining dy’t al iepen is, test hielendal neat. As d’r gjin weigering ferskynt, is it hanthaveningspunt net dêr’t jo tinke.

Hâld de applikaasje-autentikaasje nei de netwurktagong, want in kantoarútgong en in VPN-útgong steane elk foar in protte minsken en gjin fan beide identifisearret in persoan. De ynstruksje foar brûkers bliuwt koart: bring de goedkarde tunnel omheech, besykje it dan wer. Dat hâldt ien URL handich wylst de boarneregel in beslissing bliuwt en net in gissing.