Jo klant ferbynt en toant in adrespear, of ien adres mei in 255.255.255.255 masker, en de earste reaksje is dat de tsjinner wat stiks levere hat. Neat is stiks: in tunnelinterface is in punt-nei-punt-ferbining, en it masker beskriuwt it fiere ein fan dy iene ferbining, net in berik fan buorlju. It pear lêzen as lokaal en partner ferklearret it frjemde masker, de hostrûte derneist en de ûntbrekkende buorljutabel. Wat deselde lêzing net ferûntskuldiget is in adresplan dat oerlapet mei it kantoarnetwurk.

Wêrom it masker ferkeard liket op in tunnelferbining

Op in Ethernet-interface sizze in adres en in masker twa dingen: dizze host besit it adres, en alles binnen it foarheaksel is in direkte buorman. De kearn lûkt út dy twa feiten in rûte op ’e ferbining en oplost dan ferbiningsadressen foar de buorlju dy’t er oanwêzich achten. In punt-nei-punt-interface hâldt it eigendom en lit de buorlju falle, sadat it twadde adres op ’e klantrigel it fiere ein is en net in oare host op in dield segmint. Der is gjin hardware-adressearring, gjin oplossingferkear en gjin broadcastdomein om by te hearren, en dêrom gedraacht de interface him as in buis mei krekt ien bestimming.

Dêrom is in hostrûte njonken in breed masker hjir normaal en net in symptoom. Berikberens op dizze ferbining betsjut ien adres, en de kearn skriuwt krekt dat op. Lês de twa adressen tegearre foardat jo beslute dat de konfiguraasje ferkeard is, want elk op himsels liket in flater.

Twa topologyen, twa adresfoarmen

De âldere punt-nei-punt-topology jout elke klant in lyts blok en brûkt de twa middenadressen, sadat it masker as in fragmint fan in netwurk liket en net as in pool. De subnet-topology dielt in adres út ’e pool mei it poolmasker en neamt it tunneladres fan ’e tsjinner de partner. Beide leverje in jildige ferbining, en se ferskille allinnich yn hokker adressen yn it profyl ferskine en yn it masker dat in brûker wierskynlik freegje sil.

TopologyClient address shapePeerRoute to expect
Point-to-point block per clientTwo neighbouring addresses inside a small blockThe far address of that blockA single host route on the tunnel device
Shared poolOne address carrying the pool maskThe server's tunnel addressA single host route on the tunnel device

Hokker rigel ek by jo klant past, lês earst de partner, want dy neamt it fiere ein en ferklearret dêrom it masker. In profyl dat tusken tsjinners mei ferskillende topologyen kopiaat wurdt, sil de ferkearde foarm foar syn nije thús sjen litte, en dy ôfwiking wurdt maklik foar in tsjinnerflater oansjoen.

Wannear’t de pool en it kantoarnetwurk deselde bits opeaskje

Om’t de ferbining rûte wurdt, hat de pool in foarheaksel nedich dat nearne ûnder de netwurken foarkomt dy’t de tsjinner berikke kin. Diel ien en de klant hâldt ien rûte foar in berik dat twa plakken betsjut, en de rûte dy’t it lêst ynstallearre is beslút hokker plak wint. De flater lit him op ’e klant sjen, ek al heart de beslissing deryn ta it adresplan. Wat brûkers melde is dat de lokale router ferdwynt as de tunnel omheech komt, of dat allinnich guon kantoarhosts antwurdzje.

Foarheaksels dy’t gewoan opinoar lykje binne in oar gefal, en oketten mei it each ferlykje is gjin foarheakselfergeliking. Skriuw beide op en tel de maskearre bits: 192.168.4.0/24 tsjin 192.168.6.0/24 komme oerien oant bit 22 en wikselje by bit 23, om’t it tredde oket lêzen wurdt as 00000100 tsjin 00000110, dus dy twa netwurken binne echt apart. Set 10.8.0.0/24 njonken in oar 10.8.0.0/24 en alle 24 maskearre bits komme oerien, wat betsjut dat ien rûte net beide plakken útdrukke kin. De maskerlange beslút wêr’t de ferliking ophâldt, en it netwurk dat it twadde ynstallearre is, is dejinge dy’t ferliest.

Wat in rûte ferbining net leverje kin

Broadcast en multicast reizgje net oer in rûte ferbining, en ferskate bekende funksjes binne derop boud. Blêdzjylisten, nammebekendmakings en tsjinstûntdekking geane allegear út fan in dield segmint, sadat in bestânstsjinnder elk fersyk op adres beantwurdzje kin en dochs nea yn in list ferskine sil. Namme-oplossing dy’t fan link-lokale broadcast ôfhinklik is, mislearret om deselde reden, en gjin profylwiziging feroaret wat de tunnel drage kin. Oft dat wichtich is, is in fraach fan easken en net fan rûte.

In klant dy’t dy leveringen echt nedich hat, freget in brêge-interface, dy’t Ethernet-ramen draacht en dêrom it broadcastdomein hâldt. De priis is in lûdiger ferbining, it ferlies fan ’e skjinne adressearring hjirboppe beskreaun, en in folle grutter flak fan flaters sadree’t lussen ferskine. Rjochtfeardigje de eask foardat jo omskeakelje, en jou foarkar oan in nammetsjinst dy’t oer rûte ferbiningen wurket as de eask allinnich oer nammen giet.

De interface lêze foardat jo it profyl bewurkje

Freegje de kearn wat er ynstallearre hat, ynstee fan wat it profyl blykber seit. De adresútfier toant de partner dy’t it masker ferklearret, en de rûteútfier toant oft der in paad nei him bestiet. Beide tsjin it tunnelapparaat rinne litte duorret in amerijke en beslist de fraach.

ip -4 addr show dev tun0
ip route show dev tun0
ip route get 10.8.0.1

As dy trije oerienkomme, docht it profyl wat it konfigurearre is om te dwaan, en it oerbliuwende probleem leit earne oars. Feroarje de topology allinnich om in reden dy’t in ûntbrekkende mooglikheid neamt, want in ûnbekend masker is dat net.

Relatearre artikelen