It iepenjen fan de VPN-poarte lit klanten net by it LAN komme

De tunnel komt op, de klant autentisearret him, mar it LAN efter de gateway bliuwt ûnsichtber. De regel dy’t dat reparearje moast lit de VPN-poarte troch en wurket krekt sa’t er skreaun is, want dy regel regelet pakketten dy’t oan de gateway sels adressearre binne. Ferkear fan de klant nei in host efter de gateway hat in oare bestimming en in oare ketting. In slagge oanmelding feroaret net hokker fan de twa kettings de kearn besjocht.

Twa kettings, twa ferskillende bestimmingen

It lot fan in pakket wurdt bestimd troch wêr’t it hinne giet, net troch hoe’t it oankaam. Ferkear nei in adres op de gateway wurdt lokaal besoarge en tsjin ynfierregels beoardiele. Ferkear dat de gateway trochstjoert wurdt tsjin trochstjoerregels beoardiele. Deselde tunnelinterface kin beide soarten pakketten meitsje, dêrom kin ien regel net beide taken dekke.

De hiele myte yn ien sin: de listener tastean seit neat oer it netwurk der efter tastean. It binne twa aparte besluten mei aparte bewizen, en in interfacenamme op beide ferienet se net.

Wat de listenerregel eins tastiet

Listenerpakketten einigje yn it VPN-proses, en dat is krekt wat de tunnel oprjochtsje lit. De behearspagina fan de gateway en in lokale diagnostyske antwurd brûke ek it eigen ynfierpaad fan de host, dêrom slagget in test nei de gateway wylst alles der efter mislearret. Beide útkomsten binne korrekt en gjinien giet oer it LAN.

As it proses it ferkear fan de klant foar in oare bestimming dekapsulearret, komt it pakket op it trochstjoerpaad en hat dêr tastimming nedich. Slagge autentikaasje beslist wa’t de klant is; it beslist net wêr’t de klant hinne mei. De twa fragen hawwe ferskillende eigners, ferskillende logboeken en ferskillende flaterberjochten.

Test fan in klant, nea fan de gateway

In test dy’t op de gateway makke wurdt folget it eigen útpaad fan de host en kin slagje wylst it trochstjoerpaad ticht is. Begjin de test by de klant en besjoch beide einen fan de stream.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

As de oanfraach op tun0 ferskynt en der berikt neat de bestimming, dan wurdt it pakket nei oankomst weilitten, wat op trochstjoerregels of op de eigen filter fan de bestimming wiist. As der op tun0 hielendal neat ferskynt, stjoert de klant it net iens nei de tunnel, en it probleem is routing op de klant en net belied op de gateway. Fergelykje dat mei in oanfraach dy’t goed fuortgiet en neat weromkomt, wat it gefal fan de weromwei is.

Trochstjoering freget trije dingen, net ien

Trochstjoering yn de kearn moat oan stean, in filterregel moat de stream akseptearje, en de bestimming moat berikber wêze mei in paad foar it antwurd werom. As ien fan de trije mist, is de stilte fan de klant syn kant itselde.

sysctl net.ipv4.ip_forward
sudo iptables -S FORWARD
sudo iptables -S INPUT

Lês de trije útkomsten byinoar. In nul yn de earste makket de oare twa ûnbelangryk, en in standert-ferwerpbelied yn de twadde smyt de pakketten fan de klant fuort wylst it eigen ferkear fan de gateway trochgiet. De tredde útkomst lit sjen wêrom’t de listenerregel nea it probleem wie.

Hâld de twa regelsets apart yn de dokumintaasje

Skriuw de listenerregel en de regel foar de trochstjoerde tsjinst op aparte rigels, mei aparte eigners en redenen. As de VPN-poarte feroaret of in nije tsjinst publisearre wurdt, foarkomt dy skieding dat ien feroaring de oare stil ferbreedt.

Ynstee fan elke autentisearre partner as fertroud LAN-lid te behanneljen, brûk smelle regels foar de klantberikken en tsjinsten dy’t se nedich hawwe. De notysjes oer trochstjoering fan StrongSwan beskriuwe de kant fan de weromrûte en oersetting fan deselde grins, wat wer in tredde beslút is.

Ta beslút, hâld de lagen rjocht as in brûker wegere wurdt. As de oanfraach de host berikt en de applikaasje wegeret it akkount, reparearje dan de tastimming fan de applikaasje op dy laach; ferbreedzjen fan trochstjoering kin gjin oanmeldgegevens foar triemdiele leverje en sil de tagong ferbreedzje foar alle oaren dy’t suksesfol ferbine.