Twa VPN-hops efterinoar: wa sjocht echt jo ferkear?

Elk klantprofyl neamt ien tsjinner, dus fan it plak fan de brûker is der ien tunnel en ien plak dêr't beskerming einiget. Wat nei dy earste poarte bart, is in ûntwerpbeslissing dy't de klant nea sjocht, en de twa gewoane ûntwerpen hâlde har ûnder ynspeksje hiel oars. Yn in searjele keatling ûntsiferet de earste poarte en fersiferet wer. Yn in nêstele keatling hellet it in bûtenste laach fuort en stjoert in binnenste tunnel troch dy't it net iepenje kin. It oantal hops is yn beide gelyk, dêrom moat it ferskil tekene wurde en net teld.

Begjin by de klant en neam beide einen

Begjin dêr't de brûker begjint, yn it ferbiningsprofyl. It hâldt ien ôfstân adres, ien autentikaasjemetoade en, as it ûntwerp dat stipet, in list fan rûtes. Labelje dy bûtenste tunnel fan de klant nei poarte A en jou him foarbyldadressen: it tunneladres fan de klant 10.77.0.2, dat fan A 10.77.0.1 en it iepenbiere einpunt fan A 198.51.100.10, nommen út it dokumintaasjeberik TEST-NET-2 sadat neat yn it foarbyld botse kin mei in echte host.

Neat yn dat profyl neamt poarte B, en dat is gjin defekt. De twadde hop heart by A, en de iennige ferplichting fan de klant is om ferkear nei A te leverjen en te akseptearjen wat weromkomt. Oft A de tunnel beëiniget, trochstjoert of in nije iepenet, is de fraach dy't de rest fan dizze rûn beantwurdet, en dat bepaalt wat A lêze kin.

Searjeel: A ûntsiferet, fersiferet dan wer

Yn it searjele ûntwerp beëiniget A ferkear twa kear. It hellet de beskerming fan de klant fuort, krijt it IP-pakket fan de applikaasje en stjoert dat pakket dan troch in twadde tunnel dy't A nei B ta oanmakket. Tusken dy twa operaasjes sit it pakket yn it trochstjoerpaad fan A as in gewoan IP-pakket rjochte op in privee bestimming.

Dat jout twa gefolgen dy't it wurdich binne om rjochtút te sizzen. A kin belied tapasse op it binnenste pakket, yn 'e foarm fan rûtes, filterregels en logging fan boarne en bestimming, en A moat twa sets oanmeldgegevens hâlde: ien as tsjinner foar de klant en ien as klant fan B. Beskerming bestiet op elk momint, dochs feroaret it objekt dat beskerme wurdt fan identiteit by A.

Dêr folget net út dat A de platte tekst fan 'e applikaasje lêst. Wannear't de klant en de tsjinst TLS rinne litte en elkoars sertifikaten ferifiearje, sjocht A in TLS-rekordstream ynstee fan in lêsber fersyk. Befêstigje wêr't dy beskerming einiget freget in blik op 'e sertifikaatkeatling fan 'e tsjinst, net op it tunnelskema.

Nêstele: A hellet allinnich de bûtenste laach fuort

Yn it nêstele ûntwerp bout de klant earst in binnenste tunnel nei B en draacht dy tunnel dan binnen de bûtenste nei A. A stript de bûtenste kop, fynt in binnenste tunnel en stjoert dy troch sûnder syn kaaiens te hâlden, dus de binnenste beskerming einiget noch altyd by B.

Dan draacht de opgeande ferbining fan de klant twa lagen, wylst it paad tusken A en B ien draacht. A sjocht de bûtenste adressen fan 'e binnenste tunnel, wat genôch is om te witten dat der ferkear is en rûchwei wêr't it hinne giet, en net genôch om de lading te lêzen. Dat is it hiele ferskil mei it searjele gefal, en gjin hoptteller lit it sjen. Wat A noch dwaan kin, is wegerje troch te stjoeren wat it net lêze kin, en dat is altyd beskikber foar de operator fan dy poarte.

Nêsteling betellet foar dy eigenskip. Elke laach foeget kop-ekstra kosten ta, dus MTU- en MSS-planning wurdt ferplicht ynstee fan skjin, en in paad dat mei ien laach wurket kin grutte pakketten mei twa stil falle litte. Elke laach hat ek syn eigen werferbinen en libbich hâlden nedich, en in flater yn ien laach liket as in dielútfal troch de oare.

Tekenje de waarnimmers, net allinnich de tunnels

De tunnels binne it maklike part fan 'e tekening. De waarnimmers binne dêr't it ûntwerp oer giet, dus skriuw ien rige per eachpunt en folje yn wat elk echt lêze kin.

Twa rigen wurde hieltyd betize: de operator fan A en de leveransier fan 'e tunnel fan 'e klant. Se kinne ien entiteit wêze, en aparte poartenammen meitsje se net ûnôfhinklik. Unôfhinklik eigendom freget aparte bestjoerlike kontrôle, aparte oanmeldgegevens en aparte logging.

Metadaten oerlibje beide ûntwerpen. Timing, pakketgrutten en ferbiningsoantallen bliuwe by elke hop waarnimber, dus twa hops ferheegje de kosten fan korrelaasje ynstee fan it sinjaal fuort te heljen. In ûntwerp dat ûnsichtberens ûnthjit moat tsjin dy list kontrolearre wurde foardat immen derop fertrout.

Rin de flaterpaden troch foardat jo kieze

Briek dingen mei opsetsin fan 'e klant ôf, yn 'e folchoarder wêryn't in brûker se tsjinkomme soe. Begjin mei de ynterface en syn MTU, want nêsteling falt by pakketgrutte folle earder as by autentikaasje.

ip -4 addr show dev tun0
ip link show dev tun0 | grep mtu
ping -M do -s 1380 -c 2 10.77.1.1

Befêstigje dan de beskermingseinen ynstee fan se oan te nimmen. Freegje de tsjinst om syn sertifikaat fan binnenút hokker tunnel dan ek iepen is, en fergelykje de keatling dy't de klant sjocht mei de keatling dy't de tsjinst echt presintearret. In poarte dy't werûndertekenet of ûnderskept feroaret dat sertifikaat, en de ynspeksje wurdt sichtber yn ien opdracht.

openssl s_client -connect intranet.example.com:443 -brief < /dev/null

Einigje mei de werferbiningsmatriks: de tunnel fan 'e klant falt, de tunnel fan B falt, it paad tusken A en B feroaret. Notearje wat weromkomt en wat net, en oft in binnenste ferbining ea falt nei in rûte bûten syn bedoelde drager. Registrearje de adressen dy't elke test brûkte, want it werheljen op in oar tagongsnetwurk beantwurdet in oare fraach. Werhelje ek de MTU-proef nei elke werferbining, want in feroare paad kin de brûkbere grutte ferleegje sûnder dat ien konfiguraasjerige beweecht.

Kies searjeel wannear't A belied tapasse moat op it binnenste pakket, of wannear't de klant gjin twa steapelte tunnels rinne litte kin. Kies nêsteling wannear't de binnenste lading by A ûnlêsber bliuwe moat. Skriuw de kar op mei syn waarnimmers en syn MTU-sifers, en de folgjende persoan hoecht net it hiele byld opnij te tekenjen om ien fraach te beantwurdzjen.