Watter pakket moet 'n VPN-beleid vir dubbele WAN pas?

Versoeke om die VPN oor die tweede opvoer te lei, beskryf ten minste twee verskillende take, en die beleid wat die een regstel, raak nie die ander nie. In die eerste taak skuif die geënkripteerde vervoer tussen twee eindpunte na 'n ander WAN-adres. In die tweede verlaat 'n gekoppelde gebruiker se ontsleutelde toepvloei na 'n ander volgende hop. Albei is geldig, albei gebruik roetering, en elkeen het 'n passing nodig op 'n pakket wat bestaan by die punt waar die besluit geneem word. Werk die kontroles hieronder in volgorde deur, want die eerste een bepaal watter pakket latere reëls moet noem.

Noem die twee gesprekke

Stel jou 'n afgeleë werker voor wat aan 'n kantoorpoort gekoppel is en HTTPS na 'n interne toepassingbediener oopmaak. Twee onafhanklike gesprekke is op die draad, en hulle het aan elke kant verskillende adresse. Die buitenste gesprek loop tussen die twee VPN-eindpunte: poortadres na eweknie-adres, in watter protokol en poort die ontplooiing ook al onderhandel het. Die binneste gesprek loop van die adres wat aan die kliënt toegewys is na die toepassingbediener se adres op poort 443.

Die toepassing se bestemmingspoort is nie die VPN se vervoerpoort nie, en geen hoeveelheid beleid op TCP 443 sal die tonnel skuif nie. Net so sê 'n reël wat die eweknie se vervoeradres herlei niks oor waar daardie gebruiker se HTTP-versoek ná dekripsie heen gaan nie. Skryf albei gesprekke met hul werklike adresse neer voordat jy aan 'n reël raak, want die meeste verwarring op hierdie gebied kom daaruit dat 'n mens die een benoem en die ander konfigureer.

Vind waar jou beleid die pakket werklik kan sien

Die passing moet in die ketting en naamruimte geëvalueer word waar die pakket nog in die vorm is wat jy beskryf het. 'n Reël wat aan LAN-ingang geheg is, sien die binneste pakket, onversleuteld, voordat dit na die tonnel geroteer word. 'n Reël wat op plaaslik gegenereerde verkeer toegepas word, sien pakkette wat die poort self skep, en dit dek nie outomaties verkeer wat die poort bloot aanstuur nie. Geënkapsuleerde uitset is weer 'n derde geval, gewoonlik hanteer op die koppelvlak wat die tonnel dra eerder as aan die LAN-kant.

Dit is waarom dieselfde konfigurasiebrokkie op twee platforms anders optree: aanhegpunte verskil, en 'n verskaffer se beleidshaak kan voor of ná die enkripsiestap sit. Lees die pakketpad vir die spesifieke produk eerder as om die volgorde uit 'n ander verskaffer se diagram af te lei.

Bevestig die vervoer wat jy onderhandel het

Vir UDP-geënkapsuleerde IPsec plaas RFC 3948 ESP binne UDP en gebruik 'n nie-ESP-merk om IKE onderskeibaar te hou op die gedeelde poort. Gewone ESP is 'n IP-protokol, nie 'n TCP- of UDP-poort nie, so 'n firewallreël wat teen 'n poortnommer geskryf is, sal dit glad nie pas nie. Hierdie onderskeid bepaal of jou WAN-beleid 'n UDP-reël, 'n protokolreël of albei nodig het.

Onderhandelde waardes klop onthoude waardes. Lees die assosiasie se huidige poorte en adresse van die toestel af in plaas daarvan om TCP 4500 of 'n ou verskafferpoort net vir ingeval by te voeg, wat onverwante verkeer vang en die werklike klassifikasieprobleem verberg.

Kontroleer die terugpad voordat jy dit goedkeur

Sukses uitwaarts bewys die helfte van 'n ontwerp. 'n Pakket wat terugkeer na die poel van afgeleë kliënte is nie meer sigbaar onder die kliënt se adres sodra enkapsulering dit vervang nie: die buitenste bestemming is die eweknie se vervoeradres. As die tweede opvoer daardie eweknie deur 'n ander draer bereik, kan sy vertaling en filtering met die eerste een verskil, en die assosiasie moet dalk herbou eerder as gemigreer word.

Netwerkadresvertaling se toestand is die gewone slagoffer van 'n WAN-skakelaar. Teken die gekose opvoer, die verwagte buitenste bronadres, die vertaling in gebruik en die eweknie se bereikbaarheid terug na dit op, en hou dan die vervoer bereikbaar sonder om dit in die tonnel te stuur wat dit dra.

Verifieer albei lae met twee opnames

Een opname by die WAN-koppelvlak en een binne die tonnel besleg die vraag vinniger as enige konfigurasieverskil. Hardloop hulle vanaf die poort terwyl 'n goedgekeurde kliënt 'n enkele versoek doen, en hou albei lêers.

sudo tcpdump -ni wan1 'udp port 4500' -c 20
sudo tcpdump -ni tun0 'tcp port 443 and host 203.0.113.10' -c 20
ip route get 203.0.113.10 from 10.8.0.6

Die eerste opname moet die buitenste gesprek wys wat die koppelvlak verlaat wat jy bedoel het, met die verwagte bronadres. Die tweede moet die binneste gesprek een keer wys, nie gedupliseer nie, met die kliëntadres as sy bron en die toepassingbediener as sy bestemming. Die roetesoektog bevestig watter tabel die roeteerder vir daardie bron-bestemming-paar sou gebruik, en dit is waar 'n beleidsfout gewoonlik opduik. As een van die opnames nie verskyn nie, is die beslissingspunt êrens anders as die een waaraan die reël geheg is, en die regstelling hoort daar eerder as in 'n breër passing.