PPP peer helbidea edo VPN amaiera-puntua: zein doa via-n

PPP interfaze bateko lerro batek VPN kaxa bateko routing eztabaidaren zatirik handiena erabakitzen du: barneko helbidea eta haren ondoan inprimatutako peer-a. Irakurri bikote hori azpisare txiki gisa eta existitzen ez den gateway baten bila joango zara. Irakurri lotura bakarreko bi mutur gisa eta hurrengo jump-a begi-bistakoa bihurtzen da. Hemen konparazioa bi irakurketa horien artean dago, geroago eraikitzen duzun taula bakoitzak aukeratu zenuena heredatzen baitu. Kanpoko VPN amaiera-puntuari buruz ez du ezerk erabakitzen.

Interfaze-lerro baten bi irakurketa

Hartu interfazeak inet 10.64.3.9 peer 10.64.3.1/32 jakinarazten duen saio bat. Azpisare-irakurketak 10.64.3.9 /32 uharte bateko ostalari bakartzat hartzen du eta gero hortik harago zerbait lortzeko router bat bilatzen du. Lerroan dagoen beste helbide bakarra peer-a denez, irakurketa horrek 10.64.3.9 bera proposatzen du gateway gisa, eta hori zirkularra da.

Amaiera-puntuaren irakurketa dokumentatua da. Puntutik punturako interfaze batean, peer-ek lotura bakar horren urrutiko muturra izendatzen du, beraz 10.64.3.1 da erabil daitekeen hurrengo jump-a eta 10.64.3.9 beti da iturburu-helbide bat soilik.

Diferentzia horrek zehazten du via-n zer ager daitekeen. Bertan helbide lokala idazteak kernelak auzoko batekin ebatzi ezin duen ibilbide bat sortzen du, beraz sarrera balidazioan huts egiten du edo trafikoa irentsi egiten du, zerrenda batean guztiz osasuntsu agertzen den bitartean. Peer-a funtzionatzen du loturako benetako helmuga delako. Bi irakurketei kanpoko VPN amaiera-puntuari buruz ados daude, eta hori guztiz identitate bereizia da: underlay bidez lortzen da, ez berau amaitzen duen tunelaren bidez.

Saioak jadanik instalatu duena

Zure taula propioa idatzi aurretik, inprimatu loturarekin etorri dena. Onartutako PPP integrazio batek gailu-ibilbide bat eta peer-ibilbide bat instalatzen ditu normalean saioa ezartzean, eta bi sarrera horiek dagoeneko irakurketa zuzena kodetzen dute.

ip -4 addr show dev ppp0
ip route show dev ppp0
ip route show table main | head -n 5

10.64.3.1 dev ppp0 proto kernel scope link src 10.64.3.9 bezalako gailu-ibilbide batek ez du gateway-rik eramaten interfazea bera delako bidea. Peer-a via-ekin izendatzen duen ibilbidea beste objektu bat da, bizitza desberdinekoa, eta desagertu egiten da saioa erortzen denean. Bi formetako bat taula iraunkor batean kopiatzea, nola berrinstalatuko den egiaztatu gabe, ohiko arrazoia da funtzionatzen duen tunel batek berrikonexioaren ondoren bere ibilbidea galtzeko.

Konparatu bi zerrendak memoria fidatu beharrean. Peer-ibilbidea main-n badago baina zure taula gehigarria hutsik badago, helbide-lerroak inoiz esan ez dizun zerbait ikasi duzu.

Araua eta taula erabaki desberdinak dira

Taula bat hautatzea eta hura betetzea urrats independenteak dira, eta konparazioak hemen garrantzia du, biak arazketa egitean askotan nahasten baitira. Trafiko markatua 100 taulara bidaltzen duen arauak ez du ezer egiten 100 taulak bat datorren ibilbiderik ez badu, eta ondo betetako taula bateraezina da inolako arak haren bila joaten ez bada.

Ibilbide lehenetsi baten erdia ez da ibilbide lehenetsi bat. 0.0.0.0/1 bakar batek IPv4 espazioaren beheko erdia estaltzen du, beraz guztia harrapatzeko asmoa duen policy batek bat datorren 128.0.0.0/1 ere behar du, edo benetako default bat. Funtzionatzen duen konfigurazio bat irakurtzea eta bi erdietako bat kopiatzea da jendeak helmuga jakin batzuetan bakarrik hausten den routing begizta batekin amaitzeko modua.

Utzi nahita egindako salbuespenak LANean gelditu behar duten helbideentzat, eta erabaki zer gertatzen den bilaketak hautatutako taulan ezer aurkitzen ez duenean. Fallback ibilbide esplizitua errazagoa da arrazoitzeko taula huts bat baino, eta horrek unreachable emaitza ematen du eta aplikazioa gaizki bideratuta baino hondatuta agertzen da.

Galde iezaiozu bilaketari zure aplikazioak egiten duen galdera bera

ip route get-ek bide bat ebazten du; ip route show-ek gordetako sarrerak zerrendatzen ditu, eta biak ados ez egon daitezke bat oker egon gabe. Sartu iturburu-testuingurua, iturburuan oinarritutako arauak bilaketak iturburu bat daramanean bakarrik bat etortzen baitira.

ip route get 198.51.100.23 from 10.64.3.9
ip route get 198.51.100.23 from 10.64.3.9 iif ppp0
ip -4 rule show

Lehen komandoak ostalaritik egindako galdera egiten du. Bigarrenak sarrerako interfaze bat gehitzen du, aurrera bidalitako trafikoak bizi duenari hurbilago dagoena, eta erantzunak askotan beste taula bat seinalatzen du. Helmuga horietako bat ere ez da zuzeneko proba-zerbitzua; 198.51.100.23 dokumentazio-helbide bat da, beraz ordeztu probatzeko baimena duzun ostalari batekin.

Bilaketa zuzen batek ere bide bat hautatu zela frogatzen du soilik. Ez du ezer esaten beste aldeak trafikoa onartzen duen edo erantzunak arrazoibide berberaren bidez itzul daitekeen.

Non aldatzen den konparazioa

Ostalari-trafikoak eta aurrera bidalitako trafikoak ez dituzte bilaketa desberdinak egiten soilik; itzulerako bidean iragazki desberdinekin egiten dute topo. Linuxek reverse-path balidazioa aplikatzen du interfaze guztien eta hartzen duen interfazearen ezarpenetatik zorrotzenak erabiliz, beraz interfaze baten balioa aldatzeak agian ez du eragin ikusgarririk izango. Markan oinarritutako routing-ak src_valid_mark erlazioa gehitzen du, eta bertan markak bat etorri behar du iturburu bat baliozkotzat hartzeko.

Erantzunak desagertzen badira irteerako routing-a ondo dagoela dirudien bitartean, irakurri balio eraginkorrak ukitu aurretik, eta aldatu itzazu soilik adierazitako policy arrazoi batekin.

sysctl net.ipv4.conf.all.rp_filter
sysctl net.ipv4.conf.ppp0.rp_filter
sysctl net.ipv4.conf.all.src_valid_mark

Hautatu bi diseinuen artean ebidentzian oinarrituta: aplikazioa PPP helbidera lotzen bada, iturburu-arau bat eta peer-ibilbidea duen taula bat nahikoa da. Kaxak atzean duen LAN baterako aurrera bidaltzen badu, sarrerako testuinguruak eta itzulera-bideak ere bat etorri behar dute. Bat ez datozenean, zuzendu ibilbidearen jabetza, makina osorako balidazioa lasaitzen duzun ordez.