Die VPN-poort oopmaak laat kliënte nie by die LAN uitkom nie

Die tonnel kom op, die kliënt verifieer, en die LAN agter die poort bly onsigbaar. Die reël wat dit moes regstel, laat die VPN-poort deur, en dit werk presies soos geskryf, want daardie reël geld pakkette wat na die poort self gestuur word. Kliëntverkeer na ’n gasheer agter die poort het ’n ander bestemming en ’n ander ketting. ’n Suksesvolle aanmelding verander niks aan watter van die twee die kern raadpleeg nie.

Twee kettings, twee verskillende bestemmings

Die lot van ’n pakket word bepaal deur waar dit heen gaan, nie deur hoe dit aangekom het nie. Verkeer na ’n adres op die poort word plaaslik afgelewer en teen invoerreëls getoets. Verkeer wat die poort verder aanstuur, word teen aanstuurreëls getoets. Dieselfde tonnelkoppelvlak kan albei soorte pakkette lewer, en daarom kan een reël nie albei take dek nie.

Dit is die hele mite in een sin: om die luisteraar deur te laat, sê niks daaroor dat die netwerk agter hom deurgelaat word nie. Dit is twee afsonderlike besluite met afsonderlike bewyse, en ’n koppelvlaknaam op albei voeg hulle nie saam nie.

Wat die luisteraar-reël werklik toelaat

Luisteraarpakkette eindig by die VPN-proses, en dit is wat die tonnel hoegenaamd laat ontstaan. ’n Administrasiebladsy van die poort en ’n plaaslike diagnostiese antwoord gebruik ook die gasheer se eie invoerpad, en daarom slaag ’n ping na die poort terwyl alles daar agter misluk. Albei uitslae is korrek en nie een gaan oor die LAN nie.

Sodra die proses kliëntverkeer vir ’n ander bestemming dekapsuleer, betree die pakket die aanstuurpad en het dit daar toestemming nodig. Geslaagde verifikasie bepaal wie die kliënt is; dit bepaal nie waarheen die kliënt mag gaan nie. Die twee vrae het verskillende eienaars, verskillende logboeke en verskillende foutboodskappe.

Toets vanaf ’n kliënt, nooit vanaf die poort nie

Toets wat op die poort gegenereer word, volg die gasheer se eie uitvoerpad en kan slaag terwyl die aangestuurde pad toe is. Begin die toets by die kliënt en kyk na albei kante van die vloei.

nc -vz 10.40.7.25 445
tcpdump -ni tun0 host 10.40.7.25

As die versoek op tun0 verskyn en niks die bestemming bereik nie, word die pakket ná aankoms laat val, wat op aanstuurreëls of die bestemming se eie filtering dui. As niks hoegenaamd op tun0 verskyn nie, stuur die kliënt dit nie eers na die tonnel nie, en die probleem is roetering by die kliënt eerder as beleid by die poort. Vergelyk dit met ’n versoek wat korrek uitgaan en niks terugkry, wat die terugpad-geval is.

Aanstuur het drie dinge nodig, nie een nie

Kernaanstuur moet geaktiveer wees, ’n filterreël moet die vloei aanvaar, en die bestemming moet bereikbaar wees met ’n pad terug. As enige van die drie ontbreek, is die stilte vir die kliënt dieselfde.

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

Lees die drie uitsette saam. ’n Nul in die eerste maak die ander twee irrelevant, en ’n verstek-verwerp-beleid in die tweede laat die kliënt se pakkette val terwyl die poort se eie verkeer bly werk. Die derde uitset wys waarom die luisteraar-reël nooit die probleem was nie.

Hou die twee reëlstelle apart in die dokumentasie

Skryf die luisteraar-reël en die reël vir die aangestuurde diens op aparte lyne met aparte eienaars en redes. Wanneer die VPN-poort verander of ’n nuwe diens gepubliseer word, verhoed daardie skeiding dat een verandering die ander stilweg verbreed.

Gebruik smal reëls vir die kliëntreekse en dienste wat hulle nodig het eerder as om elke verifieerde portuur as ’n vertroude LAN-lid te behandel. StrongSwan se aanstuur-notas beskryf die terugroete- en vertalingskant van dieselfde grens, wat weer ’n derde besluit is.

Laastens, hou die lae reguit wanneer ’n gebruiker verwerp word. As die versoek die gasheer bereik en die toepassing weier die rekening, herstel die toepassingstoestemming op daardie laag; om aanstuur te verbreed kan nie ’n lêerdelingsbewys lewer nie, en dit sal toegang verbreed vir almal anders wat suksesvol verbind.