Bideratutako VPN bezeroa zerbitzarira iristen da, baina ez LANeko ostalarietara
Bideratutako bezero batek konekta dezake eta, hala ere, LANeko ostalari baten erantzun guztiak gal ditzake. Gehitu itzulera-bidea pasabidean, eta gero egiaztatu birbidaltzea eta paketeen iragazketa.
Tunela altxatzen da, bezeroak VPN zerbitzaria ping egiten du, eta jauzi bat urrunago dagoen makinako partekatutako karpeta batek ez du inoiz erantzuten. Bezeroaren konfigurazioan ezerk ez du hori azaltzen, eskaerak bezeroa utzi zuelako eta iritsi egin zelako. Huts egin zuen itzulerako bideak, eta huts egin zuen gailua LANeko pasabidea izan ohi da, ez VPN ostalaria. Erantzun-paketea jarraitzeak sintoma-mota osoa azaltzen du.
Jarraitu erantzunari, ez eskaerari
VPN zerbitzariak bezeroaren paketea deszifratzen du eta LANera birbidaltzen du, bezeroaren helbidea iturri-eremuan oraindik dagoela. Helmugako ostalariak helbide horri erantzuten dio, eta orain bere bideratze-taulak erabakitzen du dena. Bere lehen pasabideak ez daki ezer tunelaren multzoaz, beraz erantzuna interneteko hornitzailearen aldera irteten da eta bide horretan nonbait baztertzen da.
Bezeroan sintoma itxarote isila da: ukaziorik ez, berrezarrerarik ez, ezer ez besterik. Partekatutako karpeta arakatzean blokeatzen da, ping-ek erantzunik ez dagoela jakinarazten du, eta zerbitzariaren erregistroak osasuntsu daudela dirudi zerbitzariak bere lana egin duelako.
Jarri itzulera-bidea ostalariek begiratzen duten tokian
LANeko ostalari bakoitzak bere lehen pasabideari galdetzen dio, beraz pasabidea da tunelaren multzoa non dagoen jakin behar duen gailu bakarra. Gehitu bide estatiko bat han eta ostalari bakoitzak bide zuzena heredatzen du ukitu gabe.
Pasabideak bere helbidea DHCP aukera gisa banatzen badu, banatu bidea modu horretan makina berriek automatikoki har dezaten. Bestela bidea konfigurazio-fitxategi bakarrean bizi da eta hurrengo berreraikuntzan desagertzen da.
# on the LAN gateway; tunnel pool 172.20.5.0/24, VPN server 10.60.4.10
ip route add 172.20.5.0/24 via 10.60.4.10
ip route get 172.20.5.14
Zergatik dirudien Source NAT-ek konpontzen duela
Bezeroen multzoa VPN zerbitzariaren helbidearen atzean maskaratzeak arazoa kentzen du paketetik bezeroaren helbidea kenduz. Erantzunak zerbitzarira itzultzen dira orduan, eta hark badaki tunelera nola iritsi, eta dena funtzionatzen du. Kostua da barneko ostalariek ezin dutela bezeroa nor den ikusi, eta konexio bakoitzak makina batetik datorrela dirudiela.
Truke hori batzuetan zuzena da, adibidez hornitzaile baten gailuari bide estatikoa eman ezin zaionean. Egin araua oraingo multzoa baino zabalagoa ez dena, /24 baterako idatzitako araua hiltzen baita multzoa /16-ra zenbakitzen den egunean, eta lehen seinalea konektatzen diren eta inora iristen ez diren bezero berrien sorta da.
iptables -t nat -A POSTROUTING -s 172.20.5.0/24 -o ens18 -j MASQUERADE
iptables -t nat -L POSTROUTING -n -v
Hodeiko bideak hiru ezarpen behar ditu
VPC batean hutsune berak forma desberdinean itzultzen da, azpisareak ez baitu bezeroen barrutirako biderik. Bideratze-taulak tunelaren multzorako sarrera bat behar du instantziaren sare-interfazea helburu duena, eta interfazeak iturri eta helmuga egiaztapena itzalita behar du plataformak bere helbidea ez den iturburua duten paketeak onar ditzan. Segurtasun-taldeek eta sareko ACLek ere multzoa bi norabideetan onartu behar dute.
Utzitako bakoitzak huts egite partzial desberdin bat sortzen du. Utzi bideratze-taularen sarrera eta instantzia pribatuek erantzuten dute erantzuna multzora itzultzeko gai ez den azpisare batera. Egiaztapena piztuta dagoela, plataformak erantzuna baztertzen du instantziak jada bidali ondoren. Segurtasun-taldearen araurik gabe eskaera bera ez da inoiz iristen, eta bezeroak itxarotea geruza bat lehenago ikusten du.
Exekutatu egiaztapenak ordena honetan
Egiaztatu birbidaltzea eta iragazki-politika bideratzea erruduntzat jo aurretik, birbidaltzen ez duen ostalariak modu isilean huts egiten baitu. Gero irakurri itzulera-bidearen ezarpen eraginkorra tunela daraman interfazean, iragazki zorrotzak ustekabeko norabidetik datozen erantzunak bazter baititzake.
Amaitu LANeko ostalarian klientea ping egiten ari zela hartutako harrapaketa batekin. Erantzun paregaberik gabe iristen den eskaerak itzulera-bidea frogatzen du, eta inoiz iristen ez den eskaerak errua zerbitzarira edo tunelera itzultzen du.
sysctl net.ipv4.ip_forward net.ipv4.conf.all.rp_filter
tcpdump -ni any host 172.20.5.14 and icmp
Iturri eta helmugaren egiaztapena sare-interfaze elastikoen gidan dokumentatuta dago. Ezarri tunelaren trafikoa benetan daraman interfazean, instantzia berari konektatutako adapter arrotzean ez.